From noreply at sourceforge.net  Tue May  1 03:04:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Apr 2007 18:04:23 -0700
Subject: [Patches] [ python-Patches-1710352 ] Update locale.__all__
Message-ID: <E1Hign1-0002ol-G8@sc8-sf-web23.sourceforge.net>

Patches item #1710352, was opened at 2007-04-30 22:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1710352&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Humberto Di?genes (virtualspirit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update locale.__all__

Initial Comment:
jager:~ humberto$ python2.5
>>> import locale
>>> locale.currency
<function currency at 0x80ef0>

# Here's the problem
>>> from locale import *
>>> currency
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'currency' is not defined


I'm sending two similar patches:
 * One that adds only the two new functions in Python 2.5 (currency and format_string)
 * Other that adds every public function defined inside locale.py (I checked and they're all properly documented):
   * currency, format_string, getdefaultlocale, getlocale, getpreferredencoding, normalize and resetlocale.

I did a simple test only to assure all names are right and it worked:
for f in locale.__all__: getattr(locale, f)

Now you choose which patch is better. :)


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

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

From noreply at sourceforge.net  Tue May  1 03:04:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Apr 2007 18:04:52 -0700
Subject: [Patches] [ python-Patches-1710352 ] Update locale.__all__
Message-ID: <E1HignU-0007Gs-MA@sc8-sf-web21.sourceforge.net>

Patches item #1710352, was opened at 2007-04-30 22:04
Message generated for change (Comment added) made by virtualspirit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1710352&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Humberto Di?genes (virtualspirit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update locale.__all__

Initial Comment:
jager:~ humberto$ python2.5
>>> import locale
>>> locale.currency
<function currency at 0x80ef0>

# Here's the problem
>>> from locale import *
>>> currency
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'currency' is not defined


I'm sending two similar patches:
 * One that adds only the two new functions in Python 2.5 (currency and format_string)
 * Other that adds every public function defined inside locale.py (I checked and they're all properly documented):
   * currency, format_string, getdefaultlocale, getlocale, getpreferredencoding, normalize and resetlocale.

I did a simple test only to assure all names are right and it worked:
for f in locale.__all__: getattr(locale, f)

Now you choose which patch is better. :)


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

>Comment By: Humberto Di?genes (virtualspirit)
Date: 2007-04-30 22:04

Message:
Logged In: YES 
user_id=736405
Originator: YES

File Added: locale-2.5-currency-format_string.patch

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

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

From noreply at sourceforge.net  Tue May  1 08:08:29 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 30 Apr 2007 23:08:29 -0700
Subject: [Patches] [ python-Patches-1710352 ] Update locale.__all__
Message-ID: <E1HilXJ-0004Rt-Pl@sc8-sf-web22.sourceforge.net>

Patches item #1710352, was opened at 2007-05-01 01:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1710352&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Humberto Diogenes (virtualspirit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update locale.__all__

Initial Comment:
jager:~ humberto$ python2.5
>>> import locale
>>> locale.currency
<function currency at 0x80ef0>

# Here's the problem
>>> from locale import *
>>> currency
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'currency' is not defined


I'm sending two similar patches:
 * One that adds only the two new functions in Python 2.5 (currency and format_string)
 * Other that adds every public function defined inside locale.py (I checked and they're all properly documented):
   * currency, format_string, getdefaultlocale, getlocale, getpreferredencoding, normalize and resetlocale.

I did a simple test only to assure all names are right and it worked:
for f in locale.__all__: getattr(locale, f)

Now you choose which patch is better. :)


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-01 06:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks for the patch, fixed in rev. 55038, 55039 (2.5).

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

Comment By: Humberto Diogenes (virtualspirit)
Date: 2007-05-01 01:04

Message:
Logged In: YES 
user_id=736405
Originator: YES

File Added: locale-2.5-currency-format_string.patch

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

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

From noreply at sourceforge.net  Tue May  1 16:38:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 07:38:39 -0700
Subject: [Patches] [ python-Patches-1706039 ] Added clearerr() to clear EOF
	state
Message-ID: <E1HitV1-0000RA-12@sc8-sf-web22.sourceforge.net>

Patches item #1706039, was opened at 2007-04-23 13:21
Message generated for change (Comment added) made by belopolsky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706039&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jos (josm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added clearerr() to clear EOF state

Initial Comment:
This patch is to fix bug 1523853.
Now file.read() works as written in the doc, which says
"An empty string is returned when EOF is encountered immediately."
Before this fix, An empty string was returned even when the last
read() encountered EOF.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-05-01 10:38

Message:
Logged In: YES 
user_id=835142
Originator: NO

The latest patch works on Mac OS 10.4 . I would suggest a few cosmetic
changes:

1. Put the flag checking logic in a separate function and call it instead
of fread.  This will eliminate code duplication.
2. "else" is redundant in

+                       if (ferror(stream)) {
+                               clearerr(stream);
+                               PyErr_SetFromErrno(PyExc_IOError);
+                               return 0;
+                       } else if (feof(stream)) {
+                               clearerr(stream);
+                       }

The flow will be more obvious if you write

+                       if (ferror(stream)) {
+                               clearerr(stream);
+                               PyErr_SetFromErrno(PyExc_IOError);
+                               return 0;
+                       } 
+                       if (feof(stream)) {
+                               clearerr(stream);
+                       }

3. Please mention bug 1523853 in a comment near the test.  

otherwise, the patch looks fine.


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

Comment By: jos (josm)
Date: 2007-04-28 13:03

Message:
Logged In: YES 
user_id=1776568
Originator: YES

New patch Attached.
I believe this one includes all belopolsky's suggestions.

Now all dirty jobs are done in Py_UniversalNewlineFread:
1. calls clearerr if ferror or feof
2. set IOErrorr exception and return

The caller just checks whether IOError is occurred or not
and does appropriate jobs.

The attachment also contains unittest for this problem.

File Added: eof.diff

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-24 23:14

Message:
Logged In: YES 
user_id=835142
Originator: NO

I have just verified that this issue affects readlines and readinto
methods on Mac OS X as well.  This tells me that rather than patching all
the individual methods, maybe Py_UniversalNewlineFread should be fixed
instead.  I believe that the current situation where a function that looks
like Python API reports errors by setting flags on a FILE object instead of
settin the an exception is against python's design.  I suggest changing
Py_UniversalNewlineFgets so that if fread returns 0, it checks whether that
was due to EOF or an error and sets an exception in a case of an error and
always calls clearerr.

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

Comment By: jos (josm)
Date: 2007-04-24 13:15

Message:
Logged In: YES 
user_id=1776568
Originator: YES

I confirmed that fread can read data from fp in EOF state on Linux. On OS
X, freading from fp in EOF state doesn't work,
just return 0.

I tested this behavior using the following code.
----------------------------

#include <stdio.h>
#include <stdlib.h>

main(void)
{
  FILE *fp1, *fp2;
  int n;
  char buf[128];

  fp1 = fopen("spam.txt", "w+");
  fputs("foo", fp1);

  fseek(fp1, 0L, SEEK_END);
  if (fread(buf, 1, sizeof(buf), fp1) == 0)
    fprintf(stderr, "first fread failed\n");

  fp2 = fopen("spam.txt", "a+");
  fputs("bar", fp2);
  fclose(fp2);

  if (feof(fp1))
    fprintf(stderr, "after appending some text, fp1 is still eof\n");

  if (fread(buf, 1, sizeof(buf), fp1) == 0)
    fprintf(stderr, "second fread failed\n");
  printf("buf: %s\n", buf);

  fclose(fp1);

  return 0;
}
----------------------------
=============
On Linux
=============
first fread failed
after appending some text, fp1 is still eof
buf: bar

=============
On OS X
=============
first fread failed
after appending some text, fp1 is still eof
second fread failed
buf: 

Anyway, I think it's safe and preferable to clear EOF indicator in this
case.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-24 00:28

Message:
Logged In: YES 
user_id=835142
Originator: NO

Hmm. It looks like glibc's fread will attempt reading even if EOF flag is
already set. 

I've reproduced the problem on OS X 10.4.9 and Python 2.6a0
(trunk:54926M).

This patch fixes it.

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

Comment By: jos (josm)
Date: 2007-04-23 19:27

Message:
Logged In: YES 
user_id=1776568
Originator: YES

I can easily reproduce this problem on OS X 10.4.9 using Python 2.4.3 and
Python 2.5.

Here's the code
#################
import os, sys
filename = "spam"

f = open(filename, "w+")
f.seek(0, 2)

line = f.read() # EOF

# Writing the same file using another fd
f2 = open(filename, "a+")
f2.write("Spam")
f2.flush()
f2.close()

statinfo = os.stat(filename)
print "file size: %d" % statinfo.st_size
print "position : %d" % f.tell()
line = f.read() # read() returns emtpy!! readlines?() works ok
print "line     : [%s]" % line
#################

On my machine, it outputs the following
###
file size: 4
position : 0
line     : []
###

And just now  I found that on ubuntu on the same machine (vmware),
it works collect.
###
file size: 4
position : 0
line     : [Spam]
###

My patched version python outputs the same result as above on OS X.

We need clearerr() there, too because clearerr()'s job is not only only
clearing error indicators
but EOF indicators also.


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-23 16:22

Message:
Logged In: YES 
user_id=835142
Originator: NO

I was not able to reproduce the problem.  I tried to read through the end
of the file, append to the file from an external process and read again. 
It worked as expected: more data was read.

The proposed patch seems to be redundant: once ferror(f->f_fp) is known to
be 0, clearerr will do nothing and in the alternative branch clearerr is
already there. 

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

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

From noreply at sourceforge.net  Tue May  1 16:44:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 07:44:07 -0700
Subject: [Patches] [ python-Patches-1704547 ] Use MoveFileEx() to implement
	os.rename() on windows
Message-ID: <E1HitaJ-00015a-JP@sc8-sf-web22.sourceforge.net>

Patches item #1704547, was opened at 2007-04-20 14:48
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704547&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Martin v. L?wis (loewis)
Summary: Use MoveFileEx() to implement os.rename() on windows

Initial Comment:

This patch is to fix bug 1693753. Basically, os.rename(src, dst) fails on windows if dst already exists. This is because MoveFile() is used to implement rename. This patch replaces this API with MoveFileEx() and uses the flag MOVEFILE_REPLACE_EXISTING causing the API to replace the dst if it already exists. This brings the behaviour in line with unix. Note that, I also use the flag MOVEFILE_COPY_ALLOWED which is required if dst is on a different volume. However, moving to a different volume may not be atomic operation (I am not sure about this) as the msdn doc says that move in this case is simulated with CopyFile() and DeleteFile(). 

The patch also includes a test case and doc update. Please let me know if the location of test case and name of test function are ok. Also, MoveFileEx() is only available on NT+ windows but it should be ok as support for Win9x, WinME is removed in 2.6.


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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-01 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Martin,

Following the python-dev discussion about the topic, I would suggest that
this patch be closed along with the original bug 1693753. There doesn't
seem to be a way of implementing atomic rename() on windows. 

http://mail.python.org/pipermail/python-dev/2007-April/072887.html
http://mail.python.org/pipermail/python-dev/2007-May/072892.html

Thanks,
Raghu



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-27 00:55

Message:
Logged In: YES 
user_id=984087
Originator: YES

Ok. I will post to python-dev about this. BTW, have either of you found
any reference to MOVEFILE_REPLACE_EXISTING being atomic operation (for
intra-file system moving of course)? I couldn't find any direct reference.

Raghu.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-04-26 17:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

draghuram, I think this should be discussed on python-dev. I'd be in favor
of implementing subtle breakage, but I have been criticized for that view,
also. I agree with jorend that if there is reason to reject it in 2.6,
there is also reason to reject it forever.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-26 14:43

Message:
Logged In: YES 
user_id=984087
Originator: YES


FWIW, I googled "python os.rename windows" only to find a (very) old
discussion on python-dev about exact same topic.

http://mail.python.org/pipermail/python-dev/2001-May/014972.html

The idea of having optional parameter to os.rename() is interesting. What
do you think?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-26 11:11

Message:
Logged In: YES 
user_id=18139
Originator: NO

draghuram, Thanks, now I understand about MOVEFILE_COPY_ALLOWED.

I don't think 3.0 is the answer--it's not the "subtle breakage" release.

Eventually someone will do for the filesystem what the subprocess module
did for processes:  implement a *real* compatibility layer that behaves the
same across all supported platforms.  Until that sunny day, I think we have
to live with the quirks.  :-\


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-26 10:27

Message:
Logged In: YES 
user_id=984087
Originator: YES


I really wish one can reply to comments like in email, by quoting part of
original mail. I don't know if the new tracker allows such option. Coming
to the point,

1) MOVEFILE_COPY_ALLOWED is not needed to fix 1693753 but is needed if old
functionality needs to be maintained. The API MoveFile() does move files
across file systems (as per msdn doc).

2) As per os.rename doc, renaming across file systems *may* fail on some
unix flavors. That gave me the impression that it *may* succeed on some
others. If we can confirm that it *always* fails on *all* flavors, we can
update the doc and I can do away with MOVEFILE_COPY_ALLOWED.

3) The patch breaks exiting code behaviour as jorend noted but not
patching for that reason alone does not seem right to me, particularly
since the patch adds desirable functionality. I don't think coming up with
a new function name is a good idea. Is it ok to change the behaviour  of
rename() based on some setting in "os" module? If nothing else, the patch
can be applied to 3.0 and 2.x users can be given warnings.



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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-26 09:25

Message:
Logged In: YES 
user_id=18139
Originator: NO

loewis:  I wish I could say no.  I would prefer the new behavior.  But the
existing behavior is documented and has been there for a long time.  People
are surely relying on it in some Windows-only program somewhere.  And man,
when their code breaks, it'll break by unrecoverably clobbering files.  :( 
Still -1, sorry.


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

Comment By: Martin v. L?wis (loewis)
Date: 2007-04-26 04:06

Message:
Logged In: YES 
user_id=21627
Originator: NO

AFAICT, MOVEFILE_COPY_ALLOWED is not needed to fix 1693753. If the
objective of this patch is to establish consistency across platforms, then
this should *not* be added, since os.rename won't rename across volumes on
Unix, either. So I'm also -1 on the patch in this form.

jorend: would you still object if it only did MOVEFILE_REPLACE_EXISTING?


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-20 16:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


> This changes the documented behavior of a commonly used function.

Right. If this change is considered too big for 2.6, may be it can be
applied to 3.0? 

> FWIW:  MoveFileEx() with MOVEFILE_COPY_ALLOWED isn't transactionally
> isolated.  Other processes can see the new file being created, and
watch
> its size increase, while the old one still exists.  It isn't atomic,
> either: in certain error cases, e.g. if the process's permission to
write
> the target file is suddenly revoked, it will fail after making changes
to
> the filesystem.

True. But isn't this the case with MoveFile() too? I couldn't find any
clear mention about transactional behaviour of either MoveFile() or
MoveFileEx(). Same goes for atomicity.

> Also-- it looks like the test leaves one of the temp files lying
around!

I can take care of that. While I think about it, it is perhaps not correct
for this test function to be in Win32ErrorTests.


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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 16:47

Message:
Logged In: YES 
user_id=18139
Originator: NO

-1.  This changes the documented behavior of a commonly used function.

FWIW:  MoveFileEx() with MOVEFILE_COPY_ALLOWED isn't transactionally
isolated.  Other processes can see the new file being created, and watch
its size increase, while the old one still exists.  It isn't atomic,
either: in certain error cases, e.g. if the process's permission to write
the target file is suddenly revoked, it will fail after making changes to
the filesystem.

Also-- it looks like the test leaves one of the temp files lying around!


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

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

From noreply at sourceforge.net  Tue May  1 17:03:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 08:03:13 -0700
Subject: [Patches] [ python-Patches-1704547 ] Use MoveFileEx() to implement
	os.rename() on windows
Message-ID: <E1Hitsn-0003B1-2W@sc8-sf-web22.sourceforge.net>

Patches item #1704547, was opened at 2007-04-20 20:48
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704547&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Martin v. L?wis (loewis)
Summary: Use MoveFileEx() to implement os.rename() on windows

Initial Comment:

This patch is to fix bug 1693753. Basically, os.rename(src, dst) fails on windows if dst already exists. This is because MoveFile() is used to implement rename. This patch replaces this API with MoveFileEx() and uses the flag MOVEFILE_REPLACE_EXISTING causing the API to replace the dst if it already exists. This brings the behaviour in line with unix. Note that, I also use the flag MOVEFILE_COPY_ALLOWED which is required if dst is on a different volume. However, moving to a different volume may not be atomic operation (I am not sure about this) as the msdn doc says that move in this case is simulated with CopyFile() and DeleteFile(). 

The patch also includes a test case and doc update. Please let me know if the location of test case and name of test function are ok. Also, MoveFileEx() is only available on NT+ windows but it should be ok as support for Win9x, WinME is removed in 2.6.


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-01 16:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Martin,

Following the python-dev discussion about the topic, I would suggest that
this patch be closed along with the original bug 1693753. There doesn't
seem to be a way of implementing atomic rename() on windows. 

http://mail.python.org/pipermail/python-dev/2007-April/072887.html
http://mail.python.org/pipermail/python-dev/2007-May/072892.html

Thanks,
Raghu



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-27 06:55

Message:
Logged In: YES 
user_id=984087
Originator: YES

Ok. I will post to python-dev about this. BTW, have either of you found
any reference to MOVEFILE_REPLACE_EXISTING being atomic operation (for
intra-file system moving of course)? I couldn't find any direct reference.

Raghu.

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-04-26 23:52

Message:
Logged In: YES 
user_id=21627
Originator: NO

draghuram, I think this should be discussed on python-dev. I'd be in favor
of implementing subtle breakage, but I have been criticized for that view,
also. I agree with jorend that if there is reason to reject it in 2.6,
there is also reason to reject it forever.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-26 20:43

Message:
Logged In: YES 
user_id=984087
Originator: YES


FWIW, I googled "python os.rename windows" only to find a (very) old
discussion on python-dev about exact same topic.

http://mail.python.org/pipermail/python-dev/2001-May/014972.html

The idea of having optional parameter to os.rename() is interesting. What
do you think?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-26 17:11

Message:
Logged In: YES 
user_id=18139
Originator: NO

draghuram, Thanks, now I understand about MOVEFILE_COPY_ALLOWED.

I don't think 3.0 is the answer--it's not the "subtle breakage" release.

Eventually someone will do for the filesystem what the subprocess module
did for processes:  implement a *real* compatibility layer that behaves the
same across all supported platforms.  Until that sunny day, I think we have
to live with the quirks.  :-\


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-26 16:27

Message:
Logged In: YES 
user_id=984087
Originator: YES


I really wish one can reply to comments like in email, by quoting part of
original mail. I don't know if the new tracker allows such option. Coming
to the point,

1) MOVEFILE_COPY_ALLOWED is not needed to fix 1693753 but is needed if old
functionality needs to be maintained. The API MoveFile() does move files
across file systems (as per msdn doc).

2) As per os.rename doc, renaming across file systems *may* fail on some
unix flavors. That gave me the impression that it *may* succeed on some
others. If we can confirm that it *always* fails on *all* flavors, we can
update the doc and I can do away with MOVEFILE_COPY_ALLOWED.

3) The patch breaks exiting code behaviour as jorend noted but not
patching for that reason alone does not seem right to me, particularly
since the patch adds desirable functionality. I don't think coming up with
a new function name is a good idea. Is it ok to change the behaviour  of
rename() based on some setting in "os" module? If nothing else, the patch
can be applied to 3.0 and 2.x users can be given warnings.



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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-26 15:25

Message:
Logged In: YES 
user_id=18139
Originator: NO

loewis:  I wish I could say no.  I would prefer the new behavior.  But the
existing behavior is documented and has been there for a long time.  People
are surely relying on it in some Windows-only program somewhere.  And man,
when their code breaks, it'll break by unrecoverably clobbering files.  :( 
Still -1, sorry.


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

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

Message:
Logged In: YES 
user_id=21627
Originator: NO

AFAICT, MOVEFILE_COPY_ALLOWED is not needed to fix 1693753. If the
objective of this patch is to establish consistency across platforms, then
this should *not* be added, since os.rename won't rename across volumes on
Unix, either. So I'm also -1 on the patch in this form.

jorend: would you still object if it only did MOVEFILE_REPLACE_EXISTING?


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-20 22:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


> This changes the documented behavior of a commonly used function.

Right. If this change is considered too big for 2.6, may be it can be
applied to 3.0? 

> FWIW:  MoveFileEx() with MOVEFILE_COPY_ALLOWED isn't transactionally
> isolated.  Other processes can see the new file being created, and
watch
> its size increase, while the old one still exists.  It isn't atomic,
> either: in certain error cases, e.g. if the process's permission to
write
> the target file is suddenly revoked, it will fail after making changes
to
> the filesystem.

True. But isn't this the case with MoveFile() too? I couldn't find any
clear mention about transactional behaviour of either MoveFile() or
MoveFileEx(). Same goes for atomicity.

> Also-- it looks like the test leaves one of the temp files lying
around!

I can take care of that. While I think about it, it is perhaps not correct
for this test function to be in Win32ErrorTests.


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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 22:47

Message:
Logged In: YES 
user_id=18139
Originator: NO

-1.  This changes the documented behavior of a commonly used function.

FWIW:  MoveFileEx() with MOVEFILE_COPY_ALLOWED isn't transactionally
isolated.  Other processes can see the new file being created, and watch
its size increase, while the old one still exists.  It isn't atomic,
either: in certain error cases, e.g. if the process's permission to write
the target file is suddenly revoked, it will fail after making changes to
the filesystem.

Also-- it looks like the test leaves one of the temp files lying around!


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

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

From noreply at sourceforge.net  Tue May  1 20:55:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 11:55:44 -0700
Subject: [Patches] [ python-Patches-1704134 ] minidom Level 1 DOM compliance
Message-ID: <E1HixVo-0001ZB-PK@sc8-sf-web22.sourceforge.net>

Patches item #1704134, was opened at 2007-04-20 03:39
Message generated for change (Comment added) made by jorend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704134&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: minidom Level 1 DOM compliance

Initial Comment:
Tested on: Mac OS X 10.4.9

This patch fixes numerous bugs in xml.dom.minidom and expatbuilder.
It fixes all the small-to-middling bugs in minidom's DOM Level 1
compliance that I'm aware of; only large bugs remain (see below).

Changes: These are mainly fixes for bugs found by the W3C DOM Test
Suite for DOM Level 1.  Python 2.5 fails over 120 of these tests; I
got the number down to 48.

  - Exposed expat's XML_GetSpecifiedAttributeCount() as a method of
    pyexpat parser objects.  (This is needed to set Attr.specified
    correctly.)  Documented the new method in Doc/lib/libpyexpat.tex.

  - Attributes that got default values from the DTD didn't show up in
    the DOM.  (This was a violation of the XML 1.0 spec!  See
    http://www.w3.org/TR/REC-xml/#proc-types section 5.1, "Validating
    and Non-Validating Processors".  Even non-validating processors
    must "supply default attribute values" based on a certain subset
    of the DTD!)

  - Attr.specified is now set correctly.  Before, it was always False
    (should have been True).

  - Inserting a node into one of its descendants caused an infinite
    loop!  :-)  Now it throws HierarchyMalarkey, per the spec.

  - Many error conditions specified in the DOM were not detected.  In
    particular, InvalidCharacterErr was never raised.  The new version
    does a lot more checking.

  - Assigning to nodeValue is now a no-op for node types where it's
    defined to be null.

  - Document.createEntityReference() is implemented.  It returns an
    EntityReference node, but the node is not populated from the DTD.
    (That is, the new EntityReference implementation is compliant as
    far as it goes, but incomplete.)

  - Element.removeAttributeNode(attr) now raises NotFoundErr if
    attr belongs to some other Element and merely has the same name as
    an attribute of this Element.

  - Element.setAttributeNode() would sometimes return None erroneously.

  - Element.removeAttributeNode() now returns the removed node.

  - Several CharacterData methods would incorrectly throw if you
    passed node.length as the index.

  - Added Document.xmlVersion (from DOM Level 3).  This affects
    INVALID_CHARACTER_ERR checking as specified.

  - Added tests for all of the above.

  - Removed trailing whitespace from lines in Lib/test/test_minidom.py.

  - Deleted obsolete gc testing from test_minidom.

  - In one or two places, broke very large asserts into many small
    asserts.  (I was debugging something.  This change is inessential,
    but it's a good change, so I kept it.)


DOM Level 1 bugs remaining:

  - A lot of the readonly properties are not implemented as readonly.
    This would be easy to fix with new-style classes, but these are
    old-style classes that are using property() for a few things--I
    haven't tried to understand it yet.  I'm putting this off until
    the present patch lands.

  - All NodeLists should be live views, even the one returned by
    getElementsByName().  It will be hard to fix this while retaining
    pickle backward compatibility, and still harder to do it without
    hurting performance.

  - Attribute nodes' nodeValue and childNodes are supposed to stay in
    sync.  This has all the same problems.

  - EntityReference nodes should be populated with child nodes.  The
    descendants of EntityReference nodes should be readonly.  This is
	slightly less of a headache.


I haven't even tried to run DOMTS level2 tests yet.  I'm sure it'll be
pretty gruesome.



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

>Comment By: Jason Orendorff (jorend)
Date: 2007-05-01 14:55

Message:
Logged In: YES 
user_id=18139
Originator: YES

Martin, do I need to change anything else?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-27 22:40

Message:
Logged In: YES 
user_id=18139
Originator: YES

Martin,

This version of the patch moves name-checking into a separate module,
"xml.names".  But for now it is undocumented (intentionally).

Also, DOMImplementation.hasFeature("XMLVersion", v) now returns True for v
in ("1.0", "1.1"), and setting doc.xmlVersion to any other value raises
NotSupportedErr.  (Both these things are specified in DOM Level 3 Core
under the Document.xmlVersion attribute.)  Added a test for this, too.

I didn't make any other changes.  Let me know if I'm wrong about those
other two things.

File Added: minidom-level-1-compliance.4.patch

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-26 09:06

Message:
Logged In: YES 
user_id=18139
Originator: YES

Martin, thank you very, very much for looking at this.  Happy to
iterate.  I'll turn it around as fast as I can, probably tomorrow.

- Node.nodeValue isn't readonly; setting it raises an exception only
if the *node* is readonly.  DOM Level 2 clarifies: "When it is defined
to be null, setting it has no effect."

http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#ID-1950641247
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68D080

- I agree about moving the name-checking code out of minidom.
"xml.names" sounds fine.  Should it be official and documented?

  xml.names.is_name(name, [xmlVersion="1.0"]) -> bool
    Returns True if name matches the Name construction in the
    specified version of XML.  Raises ValueError if xmlVersion is not
    a known version of XML (currently either "1.0" or "1.1").

- Regarding xmlVersion = "1.1":  I don't think writing "fully
normalized" XML is required.  It's only a "SHOULD" in XML 1.1:

"All XML parsed entities (including document entities) SHOULD be fully
normalized [...]  However, a document is still well-formed even if it
is not fully normalized. XML processors SHOULD provide a user option
to verify that the document being processed is in fully normalized
form, and report to the application whether it is or not."

http://www.w3.org/TR/xml11/#sec-normalization-checking

DOM Level 3 provides a "normalize-characters" option.  Implementations
are not required to support it:

http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html#parameter-normalize-characters

I want to add normalization to writexml() and toxml(), but I hope it
can wait until after this patch lands.


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

Comment By: Martin v. L?wis (loewis)
Date: 2007-04-26 04:44

Message:
Logged In: YES 
user_id=21627
Originator: NO

I guess we'll need a number of iterations. Some observations:
- I read the nodeValue specification so that it raises DOMException if you
try to set it, and it is "readonly", where I interpret "readonly" as
"always null" (because it appears to be the only case where the value is
never changing). So __setattr__ should raise that exception, IMO.
- I think that the checks for correct names should be moved out of the
minidom module, into a more global place (because it might be useful
independent of minidom), e.g. xml.names. See also xml.utils.characters in
PyXML.
- Setting the xmlVersion to 1.1 should raise NOT_SUPPORTED_ERR IMO: we
cannot guarantee that we will write out correct XML 1.1 (i.e. a document
that is in Unicode normal form NFC).

More later.

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-25 08:02

Message:
Logged In: YES 
user_id=18139
Originator: YES

File Added: minidom-level-1-compliance.3.patch

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-25 02:26

Message:
Logged In: YES 
user_id=33168
Originator: NO

Jason, don't worry about the size, I was mostly complaining about the
whitespace diffs.  I know Tim hadn't done a normalization step for a while.
 I just did it and am running the tests now.  Damn there are a lot!  :-(  

The good news is that your patch will go down.  The bad news for you is
that you are going to have to regenerate it and there will probably be
conflicts.  I'm hoping Martin will review it as he's quite knowledgeable
about XML.  I doubt there is any more that I can contribute to this patch
other than to say it needs some expert eyes on it, but generally looks
good.

The tests should be done within 15 minutes or so.  Then I'll check in
whitespace normalization.

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-24 23:55

Message:
Logged In: YES 
user_id=18139
Originator: YES

OK, the updated patch has the suggested changes (Doc for EntityReference;
eliminated "pass" and added comment in Node.__setattr__).

File Added: minidom-level-1-compliance.2.patch

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-24 07:53

Message:
Logged In: YES 
user_id=18139
Originator: YES

Neal, thanks for looking at this.

Size:  Yeah.  :-\  I don't know what to do about this.  There were a lot
of bugs, so there are a lot of diffs.  :(

Whitespace:  I checked, and the extra whitespace is definitely in trunk's
Lib/test/test_minidom.py; a recent change added it.  This patch removes it.
 (I could revert the whitespace anyway, just to reduce the size of the
patch.  Let me know if I should do this.)

Doc:  Oops!  I will fix this today and upload a new patch.

pass:  Thanks, I'll change as suggested.  (Just to explain myself-- I used
"if name == 'nodeValue': pass; else: ..." because 'nodeValue' is the
special case, and the special behavior is "do nothing".  But I'm not
attached to that wording.  I'll change it.)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-24 02:58

Message:
Logged In: YES 
user_id=33168
Originator: NO

Wow this patch is big!

I notice a lot of whitespace changes, can you drop those from the patch,
it will make it easier to review.  I don't see any extra whitespace in the
original, so maybe if you ran Tools/scripts/reindent.py over the code that
would clean it up.  I think that's what Tim uses to normalize whitespace.

The new tests are good to see.  I see you added doc for a new method in
xmlparser, but the new class EntityReference from minidom.py is not
documented.

In xml/dom/minidom.py, it seems odd to see if cond: pass else: # do
something.  What about inverting the condition so pass/else is not
necessary.  The comment could be improved here as to why this is a no-op. 


The patch itself looked fine to me.  I didn't review in complete context
(ie, I didn't apply it and review all the code), just the patch itself. I
don't know enough about minidom to know if this change it good or not. 
Other than what I noted above, the patch looks decent on the surface.

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-23 09:40

Message:
Logged In: YES 
user_id=18139
Originator: YES

Justification for the most significant changes:

1.  I added a __setattr__() method to class xml.dom.minidom.Node.  This
means existing code that subclasses any of the Node classes *and* overrides
__setattr__() *and* isn't calling the base class __setattr__... will not
get the new __setattr__ functionality, which basically implements a
DOM-compatibility quirk.  I think it's OK.  :)

2.  There's a flag in pyexpat that lets you turn off default attribute
values.  The flag is marked "use with caution", because turning this off is
not XML-compliant.  expatbuilder was using the flag.  I can't tell why. 
There was no comment in the code.  I think it was just a mistake; I changed
it, and minidom passes more DOMTS tests as a result.

3.  To implement Attr.specified, I had to expose another Expat API via
pyexpat.  This was actually a pretty minor change, but I mention it because
I'm sure anyone opening this patch will be shocked that it touches any C
code.  :)

4.  Added some big regexes to check for non-XML-compliant names and raise
InvalidCharacterErr.  I didn't see a better way to do this.  If anyone is
worried about the performance hit from doing these checks, I'll look at
it.


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

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

From noreply at sourceforge.net  Wed May  2 00:35:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 01 May 2007 15:35:34 -0700
Subject: [Patches] [ python-Patches-1710853 ] PEP 318 -- add resolution and
	XRef
Message-ID: <E1Hj0wY-0006wg-B1@sc8-sf-web22.sourceforge.net>

Patches item #1710853, was opened at 2007-05-01 18:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1710853&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 318 -- add resolution and XRef

Initial Comment:
PEP 318 still lists two issues as unresolved, and some decisions as not yet final.  It says that class decorators will probably not be added to 2.4.

This adds short comments stating what the resolution was, and referring people to PEP3129, which does add class decorators.

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

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

From noreply at sourceforge.net  Wed May  2 09:14:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 00:14:27 -0700
Subject: [Patches] [ python-Patches-1710853 ] PEP 318 -- add resolution and
	XRef
Message-ID: <E1Hj92h-0006WT-JU@sc8-sf-web23.sourceforge.net>

Patches item #1710853, was opened at 2007-05-01 22:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1710853&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 318 -- add resolution and XRef

Initial Comment:
PEP 318 still lists two issues as unresolved, and some decisions as not yet final.  It says that class decorators will probably not be added to 2.4.

This adds short comments stating what the resolution was, and referring people to PEP3129, which does add class decorators.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 07:14

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, edited and committed as rev. 55071.

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

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

From noreply at sourceforge.net  Wed May  2 11:28:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 02:28:38 -0700
Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to
	random
Message-ID: <E1HjB8Y-0008Kw-7v@sc8-sf-web22.sourceforge.net>

Patches item #1681432, was opened at 2007-03-15 14:09
Message generated for change (Comment added) made by miathan6
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wladmir van der Laan (miathan6)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add triangular distribution to random

Initial Comment:
This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly.

http://en.wikipedia.org/wiki/Triangular_distribution


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

>Comment By: Wladmir van der Laan (miathan6)
Date: 2007-05-02 11:28

Message:
Logged In: YES 
user_id=49336
Originator: YES

I found one catch that we might want to avoid. If you input integers into
this function instead of floats, it breaks. It might be a good idea to wrap
the parameters in float(arg).


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-03 03:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

Will get this fixe-up and applied to Py2.6.  That is due out any time
soon, so I'll keep it on my todo list for a bit.

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

Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-17 17:54

Message:
Logged In: YES 
user_id=703403
Originator: NO

Looks correct to me, and seems to work well with correct parameters.

The arguments to the square roots are never negative; this means that we
get silent failure (that is, some distribution that isn't the triangular
distribution) if the input parameters don't satisfy left <= center <=
right.  Maybe the inputs should be checked, and a
ValueError raised on bad input?

If the test "x < (center-left)/(right-left)" is replaced by
"x*(right-left) < (center - left)" then the code does the right thing in
the limit-case when left == center == right (that is, it gives a delta
distribution at center);  currently it'll raise a ZeroDivisionError in this
case.  It's not clear to me which behaviour should be preferred.




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

Comment By: Paul Hankin (paulhankin)
Date: 2007-03-17 17:12

Message:
Logged In: YES 
user_id=1740099
Originator: NO

Some minor quibbles: the distributions in random name their parameters
after the most common use in math text books. Is n't that 'a, b, c' here
rather than 'left, right, center' (note, different order too)? Admittedly
your parameter names are clearer.

There's not total consistency in random, but it looks like
'triangularvariate' would be the right name for the function - although my
knowledge of stats is sketchy, so perhaps there's a distinction I'm not
aware of.

Indentation and spacing around operators needs fixing also.


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

Comment By: Wladmir van der Laan (miathan6)
Date: 2007-03-16 09:57

Message:
Logged In: YES 
user_id=49336
Originator: YES

Yes, I will add some tests and docs, although usage is quite
straightforward. That's the main reason also for adding this distribution,
it has three parameters which are intuitive (left, center and right) the
distribution is just a linear interpolation (P(left)=0 and P(center)=1 and
P(right)=0 ).

I am writing an event simulation and I added it because I was missing some
kind of assymetric distribution for timings; in an uniform distribution t-x
and t+y would be just as likely as t, in a gaussian distribution you can
only set sigma but not the upper and lower bound.

With all the other distributions in there I thought it might come in handy
for other people too. I also believe it has its uses in sound
generation/processing.

Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it
up at work and it seems I have this ancient version here.


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

Comment By: Collin Winter (collinwinter)
Date: 2007-03-16 03:22

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Could you work up some tests (Lib/test/test_random.py) and docs
(Doc/lib/librandom.tex) for this? An explanation of why you think this
should be included in the standard library would be helpful, too.

Also, it seems you made this patch against Python 2.3. While this
particular patch still applied (relatively) cleanly to Python 2.6a0 source,
Python 2.3 is no longer supported and most patches made against it have a
high probability of inapplicability. See http://www.python.org/dev/faq/ for
information on how to obtain a read-only checkout of the latest source
code.

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

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

From noreply at sourceforge.net  Wed May  2 18:12:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 09:12:59 -0700
Subject: [Patches] [ python-Patches-1159139 ] cgi.py invalid REQUEST_METHOD
	set
Message-ID: <E1HjHRr-0008Rz-F2@sc8-sf-web22.sourceforge.net>

Patches item #1159139, was opened at 2005-03-08 11:04
Message generated for change (Comment added) made by joesalmeri
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159139&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joe (joesalmeri)
Assigned to: Martin v. L?wis (loewis)
Summary: cgi.py invalid REQUEST_METHOD set

Initial Comment:
Python Version 2.4
OS Windows XP SP 2 + WindowsUpdates
Patch for lastest CVS Tree

When the environment does not have a correctly set 
REQUEST_METHOD cgi.py prompts
for key=value pairs by reading from sys.stdin.  After the 
values are read from sys.stdin they are never stored in 
the FieldStorage.list attribute like they are
when the FieldStorage.read_urlencoded or 
FieldStorage.read_multi methods are called.

This causes a problem when FieldStorage.keys() is 
called because although the values were read from 
sys.stdin they were never stored in FieldStorage.list.

Although you could argue that REQUEST_METHOD 
should have been set correctly in the first place, it still 
seems like if cgi.py is going to handle that situation by
actually reading the values from sys.stdin it should 
store them too.

This fix stores the values read.


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

>Comment By: Joe (joesalmeri)
Date: 2007-05-02 12:12

Message:
Logged In: YES 
user_id=1235002
Originator: YES

Was the test script sufficient or did you need any more information?

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

Comment By: Joe (joesalmeri)
Date: 2007-04-02 10:14

Message:
Logged In: YES 
user_id=1235002
Originator: YES

Test Script that shows problem:

# Start of Script
import cgi
import os

os.environ['REQUEST_METHOD'] = 'cgi'

field = cgi.FieldStorage()

print field
print field.keys()

for k in field.keys():
    print k, field[k]

# End Of Script

When you run that script it will hang because it is waiting on the read
from self.fp (sys.stdin), press ctrl-z (EOF) on Windows and hit enter (or
you could enter some key/value pairs but they are not stored in
FieldStorage).

cgi.py will then fail as follows:

^Z
FieldStorage(None, None, '')
Traceback (most recent call last):
  File "Q:\cgifix\FixTest\t2.py", line 9, in ?
    print field.keys()
  File "P:\SW\Python\lib\cgi.py", line 601, in keys
    raise TypeError, "not indexable"
TypeError: not indexable

Now modify the above script to use the NEW cgi.py I provided.
When prompted for the values on sys.stdin enter your pairs
enter the following (press enter after each line)

a=1
b=2
c=3

now press ctrl-z (EOF) and enter and you will see that cgi.py has been
patch to fix the bug.

FieldStorage(None, None, 'a=1\nb=2\nc=3\n')
['a', 'b', 'c']
a MiniFieldStorage('a', '1')
b MiniFieldStorage('b', '2')
c MiniFieldStorage('c', '3')

I hope that makes the problem and solution more clear so that this can be
included in the next release.

Thanks!





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

Comment By: Joe (joesalmeri)
Date: 2007-04-02 09:54

Message:
Logged In: YES 
user_id=1235002
Originator: YES

It been a long time since I submitted this patch but I meant that
REQUEST_METHOD is not set although I believe it also happens when it is set
incorrectly.

Regarding your question with the prompting I thought I explained that in
the original post but here are more details:

When the REQUEST_METHOD is not set the __init__ method for the
FieldStorage class ends up setting the self.fp to sys.stdin.

When the read_single method is called it calls self.read_lines().  Since
self.fp is equal to sys.stdin at that point and since there is not input
pending on stdin it ends up prompting for input until it reaches EOF.

The bug was that although it prompted for input by reading from sys.stdin,
the values that it read were never stored in FieldStorage like they are
when the values are read from the normal sources.  

Since someone went to the trouble of coding cgi.py to read the values from
stdin when the REQUEST_METHOD was invalid it seems to make sense to store
them.

As jimjjewett point out this addresses the issue of allowing a cgi script
to be called from the command line which is useful for debugging of if no
web server is running.

Since it is counter-intuitive to read the values or not store them the
other option would be not to set self.fp = sys.stdin and instead through an
error that REQUEST_METHOD was not set properly however, it seems more
benefitial to read from sys.stdin and then store the values read in
FieldStorage.

Does that make more sense now?

Thanks.












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

Comment By: SourceForge Robot (sf-robot)
Date: 2007-03-20 22:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Martin v. L?wis (loewis)
Date: 2007-03-06 08:23

Message:
Logged In: YES 
user_id=21627
Originator: NO

I must be completely missing the point of this patch. 

Where in the code does it currently prompt for key=value pairs if
REQUEST_METHOD is not correctly set?

By "not correctly set", do you mean "not set" or "set incorrectly"? If the
latter, to what value?

You seem to be modifying the read_single function. This is meant to read a
single body of the CGI request (as sent by the HTTP client), not the
key-value-pairs.

I've tried to come up with a demo application of this new functionality,
but failed: I couldn't make this new code do anything useful. What Python
script should I use, how should I invoke it, what environment variables
should I give, and what standard input?

Tentatively rejecting the patch.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-14 17:54

Message:
Logged In: YES 
user_id=764593

+1 on supporting use without a REQUEST_METHOD, if only 
to match Perl on "what happens if my .cgi was called straight 
from the command line"?
 

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

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

From noreply at sourceforge.net  Wed May  2 23:23:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 14:23:30 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HjMIM-0007Jq-AF@sc8-sf-web21.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 21:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

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

From noreply at sourceforge.net  Wed May  2 23:33:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 14:33:30 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HjMS2-0001XS-8K@sc8-sf-web24.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 21:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 21:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Thu May  3 02:12:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 17:12:14 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HjOve-0004K4-7w@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

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

From noreply at sourceforge.net  Thu May  3 02:14:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 17:14:33 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HjOxt-0003yz-1X@sc8-sf-web21.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May  3 02:22:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 02 May 2007 17:22:56 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HjP60-0004rp-4q@sc8-sf-web21.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May  3 12:03:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 03:03:58 -0700
Subject: [Patches] [ python-Patches-1706039 ] Added clearerr() to clear EOF
	state
Message-ID: <E1HjYAI-0003Xg-4j@sc8-sf-web21.sourceforge.net>

Patches item #1706039, was opened at 2007-04-23 17:21
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706039&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jos (josm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added clearerr() to clear EOF state

Initial Comment:
This patch is to fix bug 1523853.
Now file.read() works as written in the doc, which says
"An empty string is returned when EOF is encountered immediately."
Before this fix, An empty string was returned even when the last
read() encountered EOF.

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

>Comment By: jos (josm)
Date: 2007-05-03 10:03

Message:
Logged In: YES 
user_id=1776568
Originator: YES

The flag checking is revised.
I removed feof() so the checking logic become shorter.
I didn't factor out that logic 
because I think the logic is simple enough

Added a comment that mentions bug 1523853.


File Added: eof2.diff

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-05-01 14:38

Message:
Logged In: YES 
user_id=835142
Originator: NO

The latest patch works on Mac OS 10.4 . I would suggest a few cosmetic
changes:

1. Put the flag checking logic in a separate function and call it instead
of fread.  This will eliminate code duplication.
2. "else" is redundant in

+                       if (ferror(stream)) {
+                               clearerr(stream);
+                               PyErr_SetFromErrno(PyExc_IOError);
+                               return 0;
+                       } else if (feof(stream)) {
+                               clearerr(stream);
+                       }

The flow will be more obvious if you write

+                       if (ferror(stream)) {
+                               clearerr(stream);
+                               PyErr_SetFromErrno(PyExc_IOError);
+                               return 0;
+                       } 
+                       if (feof(stream)) {
+                               clearerr(stream);
+                       }

3. Please mention bug 1523853 in a comment near the test.  

otherwise, the patch looks fine.


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

Comment By: jos (josm)
Date: 2007-04-28 17:03

Message:
Logged In: YES 
user_id=1776568
Originator: YES

New patch Attached.
I believe this one includes all belopolsky's suggestions.

Now all dirty jobs are done in Py_UniversalNewlineFread:
1. calls clearerr if ferror or feof
2. set IOErrorr exception and return

The caller just checks whether IOError is occurred or not
and does appropriate jobs.

The attachment also contains unittest for this problem.

File Added: eof.diff

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 03:14

Message:
Logged In: YES 
user_id=835142
Originator: NO

I have just verified that this issue affects readlines and readinto
methods on Mac OS X as well.  This tells me that rather than patching all
the individual methods, maybe Py_UniversalNewlineFread should be fixed
instead.  I believe that the current situation where a function that looks
like Python API reports errors by setting flags on a FILE object instead of
settin the an exception is against python's design.  I suggest changing
Py_UniversalNewlineFgets so that if fread returns 0, it checks whether that
was due to EOF or an error and sets an exception in a case of an error and
always calls clearerr.

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

Comment By: jos (josm)
Date: 2007-04-24 17:15

Message:
Logged In: YES 
user_id=1776568
Originator: YES

I confirmed that fread can read data from fp in EOF state on Linux. On OS
X, freading from fp in EOF state doesn't work,
just return 0.

I tested this behavior using the following code.
----------------------------

#include <stdio.h>
#include <stdlib.h>

main(void)
{
  FILE *fp1, *fp2;
  int n;
  char buf[128];

  fp1 = fopen("spam.txt", "w+");
  fputs("foo", fp1);

  fseek(fp1, 0L, SEEK_END);
  if (fread(buf, 1, sizeof(buf), fp1) == 0)
    fprintf(stderr, "first fread failed\n");

  fp2 = fopen("spam.txt", "a+");
  fputs("bar", fp2);
  fclose(fp2);

  if (feof(fp1))
    fprintf(stderr, "after appending some text, fp1 is still eof\n");

  if (fread(buf, 1, sizeof(buf), fp1) == 0)
    fprintf(stderr, "second fread failed\n");
  printf("buf: %s\n", buf);

  fclose(fp1);

  return 0;
}
----------------------------
=============
On Linux
=============
first fread failed
after appending some text, fp1 is still eof
buf: bar

=============
On OS X
=============
first fread failed
after appending some text, fp1 is still eof
second fread failed
buf: 

Anyway, I think it's safe and preferable to clear EOF indicator in this
case.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-24 04:28

Message:
Logged In: YES 
user_id=835142
Originator: NO

Hmm. It looks like glibc's fread will attempt reading even if EOF flag is
already set. 

I've reproduced the problem on OS X 10.4.9 and Python 2.6a0
(trunk:54926M).

This patch fixes it.

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

Comment By: jos (josm)
Date: 2007-04-23 23:27

Message:
Logged In: YES 
user_id=1776568
Originator: YES

I can easily reproduce this problem on OS X 10.4.9 using Python 2.4.3 and
Python 2.5.

Here's the code
#################
import os, sys
filename = "spam"

f = open(filename, "w+")
f.seek(0, 2)

line = f.read() # EOF

# Writing the same file using another fd
f2 = open(filename, "a+")
f2.write("Spam")
f2.flush()
f2.close()

statinfo = os.stat(filename)
print "file size: %d" % statinfo.st_size
print "position : %d" % f.tell()
line = f.read() # read() returns emtpy!! readlines?() works ok
print "line     : [%s]" % line
#################

On my machine, it outputs the following
###
file size: 4
position : 0
line     : []
###

And just now  I found that on ubuntu on the same machine (vmware),
it works collect.
###
file size: 4
position : 0
line     : [Spam]
###

My patched version python outputs the same result as above on OS X.

We need clearerr() there, too because clearerr()'s job is not only only
clearing error indicators
but EOF indicators also.


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-23 20:22

Message:
Logged In: YES 
user_id=835142
Originator: NO

I was not able to reproduce the problem.  I tried to read through the end
of the file, append to the file from an external process and read again. 
It worked as expected: more data was read.

The proposed patch seems to be redundant: once ferror(f->f_fp) is known to
be 0, clearerr will do nothing and in the alternative branch clearerr is
already there. 

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

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

From noreply at sourceforge.net  Thu May  3 21:42:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 03 May 2007 12:42:36 -0700
Subject: [Patches] [ python-Patches-1703286 ] bug fix: ctypes truncates
	64-bit pointers
Message-ID: <E1HjhCG-0005Vi-OT@sc8-sf-web23.sourceforge.net>

Patches item #1703286, was opened at 2007-04-19 00:09
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Thomas Heller (theller)
Summary: bug fix: ctypes truncates 64-bit pointers

Initial Comment:
At several places _ctypes module converts a python integer to a void* pointer by first extracting an argument into an int.  Attached patch changes int to Py_ssize_t that is guaranteed to be wide enough to hold a pointer. 

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

>Comment By: Thomas Heller (theller)
Date: 2007-05-03 21:42

Message:
Logged In: YES 
user_id=11105
Originator: NO

IMO the patch is still incorrect.  Py_ssize_t cannot be used since
sizeof(Py_ssize_t) != sizeof(void *) in older Python versions.  Also, the
'n' typecode cannot be used in PyArg_Parse for the same reason.

I attach _ctypes-callproc-2.patch, which demonstrates one approach that I
think should work.  If you can verify that it works I'll apply it.

I am not sure it is possible to write really cross-platform test cases.
File Added: _ctypes-callproc-2.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-20 23:07

Message:
Logged In: YES 
user_id=835142
Originator: YES

I think you meant FreeLibrary function.  LoadLibrary seems ok.

I am attaching a new patch that should be pre-2.5 compatible and which
extends to FreeLibrary.  I don't have access to windows, so please
check/test that it works.
File Added: _ctypes-callproc-1.patch

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

Comment By: Thomas Heller (theller)
Date: 2007-04-20 21:33

Message:
Logged In: YES 
user_id=11105
Originator: NO

The patch is only correct for Python2.5 and later, earlier Python versions
don't have the Py_ssize_t type (or, when it's defined, it has still the
same size as int in these versions).  Unfortunately the 'n' typecode also
isn't available in these versions.

Also the patch has to be extended for Windows, the LoadLibrary function
has the same problem.

Would you like to extend this patch (for Windows, I can do it myself
later)?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 08:49

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas would be the best person to answer you question about where it
should go.  Maybe he has some other ideas how to test this.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 08:44

Message:
Logged In: YES 
user_id=835142
Originator: YES

Here are (failing) test cases:

Python 2.5 (r25:51908, Oct  4 2006, 18:25:28) 
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> dlopen('libc.so.6')
182896775816
>>> dlclose(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> dlsym(_, 'printf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_function(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_cdeclfunction(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum


With the patch:

>>> from _ctypes import *
>>> dlopen('libc.so.6')
182894214624
>>> dlclose(_)

I don't know how to meaningfully exercise call_function and
call_cdeclfunction to trigger the bug because in the default (small memory)
model on AMD64 function pointers always fit into 32 bits.  Maybe a
pseudo-function pointer created by an ffi callback can be used for this
purpose.

I am not sure where these test belong in the testsuit.  Maybe in
ctypes/test/test_loading.py? 





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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 07:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch.  The changes look correct, however, can you create a
test for these cases?

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

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

From noreply at sourceforge.net  Fri May  4 21:13:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 12:13:59 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for bug 1712742
Message-ID: <E1Hk3E7-0000nT-Cz@sc8-sf-web23.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bug 1712742

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

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

From noreply at sourceforge.net  Fri May  4 21:15:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 12:15:57 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for bug 1712742
Message-ID: <E1Hk3G1-0004mG-Lu@sc8-sf-web24.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bug 1712742

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Fri May  4 21:59:39 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 12:59:39 -0700
Subject: [Patches] [ python-Patches-1703286 ] bug fix: ctypes truncates
	64-bit pointers
Message-ID: <E1Hk3wJ-00008x-C8@sc8-sf-web22.sourceforge.net>

Patches item #1703286, was opened at 2007-04-19 00:09
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Thomas Heller (theller)
Summary: bug fix: ctypes truncates 64-bit pointers

Initial Comment:
At several places _ctypes module converts a python integer to a void* pointer by first extracting an argument into an int.  Attached patch changes int to Py_ssize_t that is guaranteed to be wide enough to hold a pointer. 

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

>Comment By: Thomas Heller (theller)
Date: 2007-05-04 21:59

Message:
Logged In: YES 
user_id=11105
Originator: NO

Fixed in SVN trunk revisions 55129/55131.  I will backport the patch to
the release25-maint branch later.

belopolsky, thanks for your efforts - I hope the changes work for you.

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

Comment By: Thomas Heller (theller)
Date: 2007-05-03 21:42

Message:
Logged In: YES 
user_id=11105
Originator: NO

IMO the patch is still incorrect.  Py_ssize_t cannot be used since
sizeof(Py_ssize_t) != sizeof(void *) in older Python versions.  Also, the
'n' typecode cannot be used in PyArg_Parse for the same reason.

I attach _ctypes-callproc-2.patch, which demonstrates one approach that I
think should work.  If you can verify that it works I'll apply it.

I am not sure it is possible to write really cross-platform test cases.
File Added: _ctypes-callproc-2.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-20 23:07

Message:
Logged In: YES 
user_id=835142
Originator: YES

I think you meant FreeLibrary function.  LoadLibrary seems ok.

I am attaching a new patch that should be pre-2.5 compatible and which
extends to FreeLibrary.  I don't have access to windows, so please
check/test that it works.
File Added: _ctypes-callproc-1.patch

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

Comment By: Thomas Heller (theller)
Date: 2007-04-20 21:33

Message:
Logged In: YES 
user_id=11105
Originator: NO

The patch is only correct for Python2.5 and later, earlier Python versions
don't have the Py_ssize_t type (or, when it's defined, it has still the
same size as int in these versions).  Unfortunately the 'n' typecode also
isn't available in these versions.

Also the patch has to be extended for Windows, the LoadLibrary function
has the same problem.

Would you like to extend this patch (for Windows, I can do it myself
later)?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 08:49

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thomas would be the best person to answer you question about where it
should go.  Maybe he has some other ideas how to test this.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-19 08:44

Message:
Logged In: YES 
user_id=835142
Originator: YES

Here are (failing) test cases:

Python 2.5 (r25:51908, Oct  4 2006, 18:25:28) 
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> dlopen('libc.so.6')
182896775816
>>> dlclose(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> dlsym(_, 'printf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_function(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> call_cdeclfunction(_, ()) # pretend that _ is a function pointer
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum


With the patch:

>>> from _ctypes import *
>>> dlopen('libc.so.6')
182894214624
>>> dlclose(_)

I don't know how to meaningfully exercise call_function and
call_cdeclfunction to trigger the bug because in the default (small memory)
model on AMD64 function pointers always fit into 32 bits.  Maybe a
pseudo-function pointer created by an ffi callback can be used for this
purpose.

I am not sure where these test belong in the testsuit.  Maybe in
ctypes/test/test_loading.py? 





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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-19 07:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch.  The changes look correct, however, can you create a
test for these cases?

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

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

From noreply at sourceforge.net  Sat May  5 04:35:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 19:35:58 -0700
Subject: [Patches] [ python-Patches-1713234 ] Fix warnings related to
	PyLong_FromVoidPtr
Message-ID: <E1HkA7q-0006Th-AX@sc8-sf-web23.sourceforge.net>

Patches item #1713234, was opened at 2007-05-05 11:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713234&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix warnings related to PyLong_FromVoidPtr

Initial Comment:
This is slight fix.
PyLong_FromVoidPtr(void *) causes warning on
Modules/_ctypes/callbacks.c (line 387)
> PyObject *py_rclsid = PyLong_FromVoidPtr(rclsid);
>>>> this gets rid of constness of void pointer


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

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

From noreply at sourceforge.net  Sat May  5 04:36:36 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 19:36:36 -0700
Subject: [Patches] [ python-Patches-1713234 ] Fix warnings related to
	PyLong_FromVoidPtr
Message-ID: <E1HkA8S-0006Zt-Ed@sc8-sf-web23.sourceforge.net>

Patches item #1713234, was opened at 2007-05-05 11:35
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713234&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix warnings related to PyLong_FromVoidPtr

Initial Comment:
This is slight fix.
PyLong_FromVoidPtr(void *) causes warning on
Modules/_ctypes/callbacks.c (line 387)
> PyObject *py_rclsid = PyLong_FromVoidPtr(rclsid);
>>>> this gets rid of constness of void pointer


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

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

From noreply at sourceforge.net  Sat May  5 07:08:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 04 May 2007 22:08:50 -0700
Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter
	Unpacking [PEP3113]
Message-ID: <E1HkCVm-00006y-3F@sc8-sf-web23.sourceforge.net>

Patches item #1678060, was opened at 2007-03-10 13:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Lownds (tonylownds)
Assigned to: Brett Cannon (bcannon)
Summary: Removal of Tuple Parameter Unpacking [PEP3113]

Initial Comment:
Remove tuple parameter unpacking. The Grammar is now:

typedargslist: ((tfpdef ['=' test] ',')*
                ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef)
                | tfpdef ['=' test] (',' tfpdef ['=' test])* [','])
tfpdef: NAME [':' test]
varargslist: ((vfpdef ['=' test] ',')*
              ('*' [vfpdef] (',' vfpdef ['=' test])*  [',' '**' vfpdef] | '**' vfpdef)
              | vfpdef ['=' test] (',' vfpdef ['=' test])* [','])
vfpdef: NAME

Tuple parameters are removed from Lib/.

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

>Comment By: Brett Cannon (bcannon)
Date: 2007-05-04 22:08

Message:
Logged In: YES 
user_id=357491
Originator: NO

Just so that Tony knows, this patch is next on my TODO list for Python. 
And I will be reviewing your patch instead of doing a blind 2to3
translation.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-23 09:30

Message:
Logged In: YES 
user_id=764593
Originator: NO

Brett,

2to3 is an important tool, but probably won't ever match good hand-work.

(1)  There are several places where he improved the code.

replacing map + an unpacking nested function with a generator:
"""
 def classify_class_attrs(object):
     """Wrap inspect.classify_class_attrs, with fixup for data
descriptors."""
-    def fixup((name, kind, cls, value)):
+    for (name, kind, cls, value) in
inspect.classify_class_attrs(object):
         if inspect.isdatadescriptor(value):
             kind = 'data descriptor'
-        return name, kind, cls, value
-    return map(fixup, inspect.classify_class_attrs(object))
+        yield name, kind, cls, value
"""


Replacing a paren-laden lambda with named function:
"""
-            items = sorted(items, key=lambda (k, v): (str(type(k)), k,
v))
+            def sortkey(item):
+                key, value = item
+                return str(type(key)), key, value
+            items = sorted(items, key=sortkey)
"""

Replacing filter + lambda + unpack with list comprehension:
"""
-        attrs = filter(lambda (name, kind, cls, value):
visiblename(name),
-                       classify_class_attrs(object))
+        attrs = [(name, kind, cls, value)
+                 for name, kind, cls, value in
classify_class_attrs(object)
+                 if visiblename(name)]
"""


(2)  His names are better.

I prefer his (name, result, expected)) over the current (name, (v1,v2),
(e1,e2))), let alone (name, _v1_v2_, _e1_e2_))

Even looking just at code with good existing names, he uses components
instead of _scheme_netloc_url_query_fragment_

So we get (what looks like human-readable source)

-def urlunsplit((scheme, netloc, url, query, fragment)):
+def urlunsplit(components):
+    (scheme, netloc, url, query, fragment) = components

instead of (what looks like the output of a computer translation step)

+def urlunsplit(_scheme_netloc_url_query_fragment_):
+    (scheme, netloc, url, query, fragment) =
_scheme_netloc_url_query_fragment_




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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 16:59

Message:
Logged In: YES 
user_id=357491
Originator: NO

The reason I mention using 2to3 is Collin has done a bunch of work on it
in order to make it also work with lambda.  I believe he also cleaned up
the generated names.

And as for cleaning up the patches, Tony, I can easily edit the diff file
manually, but thanks for the offer.  But if I need you to I will let you
know.

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-22 14:53

Message:
Logged In: YES 
user_id=24100
Originator: YES

Thanks for the comments.

Re: "stuff", if you look at other parts of the code, that is how the
triple is referred to -- fyi on how the name "stuff" came to be :) I was
also at a loss for a better name, and went with the contextual references.

Re: using 2to3 -- Brett, in many cases I actually tried to come up with a
consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like
that. Or it did when I last tried. Anyway, if you end up using 2to3, I
would really appreciate it if you also picked up the inspect.py docstring
change.

Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is
generated code, and that is why "repr" is used. I chose to change the
generation source rather than the generation machinery as I was changing
the source anyway, to account for the changes to parameter syntax. That is
why there are API changes. Given that other API changes were made and those
class constructors are more or less an internal API (created through
compiler.parse),
I believe this is the best way of dealing with the changes.

Brett, If you need me to remove the 2to3 doc toolchain patches, I can do
that.


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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 12:57

Message:
Logged In: YES 
user_id=357491
Originator: NO

Chances are I will take Tony's patch for its removal of the feature and
use 2to3 to handle the conversion as much as possible.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:57

Message:
Logged In: YES 
user_id=764593
Originator: NO

On the reprs, is there a reason to call repr instead of using %r?

For example, the Floordiv repr changed to:

"FloorDiv(%s, %s)" % (repr(self.left), repr(self.right))

Why not "FloorDiv(%r, %r)" % (self.left, self.right)

or even, (assuming PEP 3101 with locals,)

"FloorDiv({self.left:r}, {self.right:r})".format()

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:47

Message:
Logged In: YES 
user_id=764593
Originator: NO

Not sure if any of these are really problems, and it looks like Tony
already looked them over before submitting, but still worth mentioning...

(1)  This does more than take out tuples, though the other changes do also
look like things that ought to change for py3k.

(2)  I was amused by the name "stuff", but I couldn't think of a better
name for that particular grouping.  (suffix, mode, type)

(3)  There are some signature changes, where the unpacking is now done by
the caller, such as 

 class LeftShift(Node):
-    def __init__(self, (left, right), lineno=None):
+    def __init__(self, left, right, lineno=None):

(4)  The pdb change marks could be shortened a bit.  That shouldn't matter
for patching, but I'll post it here since it helped me.

-    def user_exception(self, frame, (exc_type, exc_value,
exc_traceback)):
+    def user_exception(self, frame, exc_info):
         """This function is called if an exception occurs,
         but only if we are to stop at or just below this level."""
+        (exc_type, exc_value, exc_traceback) = exc_info
         frame.f_locals['__exception__'] = exc_type, exc_value      
-        if type(exc_type) == type(''):
-            exc_type_name = exc_type
-        else: exc_type_name = exc_type.__name__
+        exc_type_name = exc_type.__name__
         print(exc_type_name + ':', _saferepr(exc_value),
file=self.stdout)
         self.interaction(frame, exc_traceback)


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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-12 08:07

Message:
Logged In: YES 
user_id=24100
Originator: YES

I found some more code to be removed + a docstring fix in inspect.py.
getfullargspec's docstring lists the 
wrong order for return values. This patch combined the refmanual patch,
previous simplified args patch, 
and 2to3 changes on some doc building tools.

File Added: simplified-args.patch

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-11 15:34

Message:
Logged In: YES 
user_id=24100
Originator: YES

File Added: refmanual.patch

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

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

From noreply at sourceforge.net  Sat May  5 11:02:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 02:02:40 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for bug 1712742
Message-ID: <E1HkGA4-0002fQ-K3@sc8-sf-web23.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 19:13
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bug 1712742

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: jos (josm)
Date: 2007-05-05 09:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 19:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Sat May  5 15:25:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 06:25:52 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HkKGm-0000g8-7d@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Sat May  5 18:38:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 09:38:13 -0700
Subject: [Patches] [ python-Patches-1713234 ] Fix warnings related to
	PyLong_FromVoidPtr
Message-ID: <E1HkNGv-0005dy-Nd@sc8-sf-web24.sourceforge.net>

Patches item #1713234, was opened at 2007-05-05 04:35
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713234&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix warnings related to PyLong_FromVoidPtr

Initial Comment:
This is slight fix.
PyLong_FromVoidPtr(void *) causes warning on
Modules/_ctypes/callbacks.c (line 387)
> PyObject *py_rclsid = PyLong_FromVoidPtr(rclsid);
>>>> this gets rid of constness of void pointer


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

>Comment By: Thomas Heller (theller)
Date: 2007-05-05 18:38

Message:
Logged In: YES 
user_id=11105
Originator: NO

The compiler warnings in Modules/_ctypes/callbacks.c are easily fixed by
adding explicit casts:

		PyObject *py_rclsid = PyLong_FromVoidPtr((void *)rclsid);
		PyObject *py_riid = PyLong_FromVoidPtr((void *)riid);

On the other hand, IMO it makes sense to change the signature of
PyLong_FromVoidPtr to accept 'const void *' pointers.

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

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

From noreply at sourceforge.net  Sat May  5 19:28:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 05 May 2007 10:28:34 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HkO3e-00035f-2i@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From mycorvette50 at comcast.net  Sat May  5 23:36:47 2007
From: mycorvette50 at comcast.net (waverly haines)
Date: Sat, 5 May 2007 17:36:47 -0400
Subject: [Patches]  FW: Get Free PPV N_ow
Message-ID: <000501c78f5d$800fd440$6401a8c0@waverly>

please send me filter.
John Ferguson    10 Birch Drive Mount Laurel,NJ 08054  John55NJ at comcast.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20070505/47924ea2/attachment.htm 

From noreply at sourceforge.net  Sun May  6 11:58:00 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 02:58:00 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HkdVA-0007ME-Kb@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Sun May  6 17:53:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 08:53:34 -0700
Subject: [Patches] [ python-Patches-1713797 ] Fix off-by-one error in
	Modules/socketmodule.c
Message-ID: <E1Hkj3G-0004K0-Mf@sc8-sf-web24.sourceforge.net>

Patches item #1713797, was opened at 2007-05-06 17:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713797&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bryan ?stergaard (kloeri)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix off-by-one error in Modules/socketmodule.c

Initial Comment:
This patch fixes an off-by-one error caught by propolice. See https://bugs.gentoo.org/show_bug.cgi?id=82469 for more info.

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

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

From noreply at sourceforge.net  Sun May  6 18:05:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 09:05:13 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HkjEX-0005br-Ng@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Sun May  6 18:14:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 09:14:35 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HkjNb-00038q-02@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Sun May  6 18:44:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 09:44:21 -0700
Subject: [Patches] [ python-Patches-1713797 ] Fix off-by-one error in
	Modules/socketmodule.c
Message-ID: <E1HkjqP-0001lX-4j@sc8-sf-web21.sourceforge.net>

Patches item #1713797, was opened at 2007-05-06 15:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713797&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Bryan ?stergaard (kloeri)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix off-by-one error in Modules/socketmodule.c

Initial Comment:
This patch fixes an off-by-one error caught by propolice. See https://bugs.gentoo.org/show_bug.cgi?id=82469 for more info.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-06 16:44

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks for the patch, this seems to be already fixed in Subversion.

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

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

From noreply at sourceforge.net  Sun May  6 20:41:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 06 May 2007 11:41:54 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HklgA-0005cc-EQ@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-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=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: wpy (wpy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

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

From noreply at sourceforge.net  Mon May  7 16:49:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 07:49:25 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for bug 1712742
Message-ID: <E1Hl4Wj-0000AH-LZ@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bug 1712742

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Mon May  7 19:06:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:06:55 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1Hl6fn-00004w-IU@sc8-sf-web21.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 20:41
Message generated for change (Comment added) made by wpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: wpy (wpy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: wpy (wpy)
Date: 2007-05-07 19:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Mon May  7 19:51:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:51:59 -0700
Subject: [Patches] [ python-Patches-1546078 ] xrange that supports longs, etc
Message-ID: <E1Hl7NP-00058U-Mn@sc8-sf-web21.sourceforge.net>

Patches item #1546078, was opened at 2006-08-24 09:20
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546078&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
>Group: Python 3000
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: xrange that supports longs, etc

Initial Comment:
This patch is not ready for prime-time.  It has various
crap in it that needs to be cleaned up.  I just wanted
to put the current state up so we don't lose it.  Once
we decide on the direction this should take for 2.6 and
3k, I can finish off the patch.

There is the change to rangeobject.c which contains the
bulk of the changes.  The bltinmodule.c change is only
to support exporting the xrange iter to the python
version of xrange.

I've attached the xrange impl I've been playing with
too.  It may require some tweaks when you make little
changes.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 18:03

Message:
Logged In: YES 
user_id=33168

I've attached a new version.  This has all the bootstrapping
necessary to import xrange and set it up properly.

The C code is still a bit sloppy.  The python version (which
is the only one used except for the xrange iterator over C
longs), is pretty clean and should work on the entire test
suite.

The python version has some additional features, at least
supporting negative indices.  It also warns on floats, not
sure if the C version does that or not.

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

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

From noreply at sourceforge.net  Mon May  7 19:51:59 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:51:59 -0700
Subject: [Patches] [ python-Patches-1472639 ] make range be xrange
Message-ID: <E1Hl7NP-00058X-Oj@sc8-sf-web21.sourceforge.net>

Patches item #1472639, was opened at 2006-04-18 15:40
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472639&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Wouters (twouters)
Assigned to: Neal Norwitz (nnorwitz)
Summary: make range be xrange

Initial Comment:
As discussed (in private email), make range an alias
for xrange and see howmuch breaks ;)

Aside from Python/bltinmodule.c, 31 files had to be
changed: 3 modules (but one of them was a doctest in
doctest), 2 test output files (for profile and
cProfile), and 26 tests. The predominant breakage in
tests was due to tests using range() to express
expected-test-output, and comparing it with the output
list. Another fair sized portion (particularly of
doctests, and including the doctest in doctest itself
that had to be updated) broke because of reliance on
the repr of range(). Only a few tests broke because of
xrange() being immutable (mostly tests that were
actually testing list-behaviour, like item- and
slice-assignment, on a list created by range()), but
that were all two real breakages in actual modules. The
only place that broke because xrange can't handle longs
was the test for range() that tested whether it'd take
longs. Overall, ~185 lines had to be changed.

The patch still breaks a test: the test to see if
range() does proper checks on its arguments (using the
'badint' class in test_builtin.) I didn't fix it to
remind myself that xrange() should be made to operate
on longs :) (It currently fails because xrange() will
turn all its arguments into C long integers before it
does any checks.)


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-26 21:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Updating a checkpoint which patches everything in the library.  Also has a
non-working version of xrange.  I haven't ported this from 2.6 to the
int/long unification.  This is just in case my laptop crashes.  Hopefully
I'll finish this up tomorrow and check in.

Most of the tests pass.  There are only a few issues AFAIK, like
test_xrange (big surprise) and test_repr.  Basically the longs aren't done.
 I'm not sure about floats.  Floats should be rejected in 3k.
File Added: xrange.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-12-27 17:39

Message:
Logged In: YES 
user_id=6380
Originator: NO

Ping?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-08-26 13:20

Message:
Logged In: YES 
user_id=6380

For Neal to close when his range/xrange patch is uploaded.

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

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

From noreply at sourceforge.net  Mon May  7 19:56:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 10:56:24 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1Hl7Rg-0008Qu-KC@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 20:41
Message generated for change (Comment added) made by wpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: wpy (wpy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: wpy (wpy)
Date: 2007-05-07 19:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: wpy (wpy)
Date: 2007-05-07 19:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Mon May  7 21:18:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 12:18:31 -0700
Subject: [Patches] [ python-Patches-1671208 ] Class Decorators
Message-ID: <E1Hl8j9-00089Z-V8@sc8-sf-web24.sourceforge.net>

Patches item #1671208, was opened at 2007-02-28 15:40
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671208&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jack Diederich (jackdied)
Assigned to: Jack Diederich (jackdied)
Summary: Class Decorators

Initial Comment:
Patch is against rev 54035 on the pyk3 branch
PEP will be on the 3k list shortly.

Grammar/Grammar is changed from

   funcdef: [decorators] 'def' NAME parameters ['->' test] ':' suite

to

    decorated_thing: decorators (classdef | funcdef)
    funcdef: 'def' NAME parameters ['->' test] ':' suite



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-07 15:18

Message:
Logged In: YES 
user_id=6380
Originator: NO

Jack, this patch is out of date w.r.t. the current p3yk branch. Given the
impending acceptance of PEP 3129, could you update it?

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

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

From noreply at sourceforge.net  Tue May  8 04:54:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 19:54:23 -0700
Subject: [Patches] [ python-Patches-1714700 ] os.linesep needs clarification
Message-ID: <E1HlFqJ-0008EB-Ua@sc8-sf-web23.sourceforge.net>

Patches item #1714700, was opened at 2007-05-07 23:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1714700&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.linesep needs clarification

Initial Comment:
On bug #1714381 (and in a message on a local Python list), people were trying to write a text file in this "portable" way:

f = open("filename","w")
f.write("Text" + os.linesep)
f.close()

Of course this is wrong, because the "portable" line terminator is just "\n", which gets converted into os.linesep by the C runtime library.

This patch adds a warning to the os.linesep documentation (and fixes a misplaced line break).


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

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

From noreply at sourceforge.net  Tue May  8 04:58:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 07 May 2007 19:58:16 -0700
Subject: [Patches] [ python-Patches-1714700 ] os.linesep needs clarification
Message-ID: <E1HlFu4-0000CM-3q@sc8-sf-web23.sourceforge.net>

Patches item #1714700, was opened at 2007-05-07 23:54
Message generated for change (Comment added) made by gagenellina
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1714700&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.linesep needs clarification

Initial Comment:
On bug #1714381 (and in a message on a local Python list), people were trying to write a text file in this "portable" way:

f = open("filename","w")
f.write("Text" + os.linesep)
f.close()

Of course this is wrong, because the "portable" line terminator is just "\n", which gets converted into os.linesep by the C runtime library.

This patch adds a warning to the os.linesep documentation (and fixes a misplaced line break).


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

>Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-07 23:58

Message:
Logged In: YES 
user_id=479790
Originator: YES

File Added: oslinesep.diff

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

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

From noreply at sourceforge.net  Tue May  8 16:12:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 07:12:40 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HlQQi-0002C3-2k@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 20:41
Message generated for change (Comment added) made by wpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: wpy (wpy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: wpy (wpy)
Date: 2007-05-08 16:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: wpy (wpy)
Date: 2007-05-07 19:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: wpy (wpy)
Date: 2007-05-07 19:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Tue May  8 21:28:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 12:28:56 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HlVMm-0000Pt-0w@sc8-sf-web24.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Settings changed) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
>Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Wed May  9 02:09:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 17:09:57 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HlZkj-00058o-4c@sc8-sf-web22.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 17:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:09

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks good.  I'm accepting PEP and patch.  Check it in already!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 17:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Wed May  9 02:10:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 17:10:50 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HlZla-0006Zy-5K@sc8-sf-web21.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 14:41
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: alex_gb (wpy)
>Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: alex_gb (wpy)
Date: 2007-05-08 10:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: alex_gb (wpy)
Date: 2007-05-07 13:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: alex_gb (wpy)
Date: 2007-05-07 13:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Wed May  9 02:17:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 17:17:13 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HlZrl-0005uG-Ox@sc8-sf-web23.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 17:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Georg Brandl (gbrandl)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:17

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hold on, test_parser started failing for me.  Things like this (lots of
variations):

======================================================================
FAIL: test_assert (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 176, in test_assert
    self.check_suite("assert alo < ahi and blo < bhi\n")
  File "Lib/test/test_parser.py", line 28, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 19, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'assert alo < ahi and blo < bhi\n':
illegal assert statement


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:09

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks good.  I'm accepting PEP and patch.  Check it in already!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 17:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Wed May  9 08:56:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 08 May 2007 23:56:12 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hlg5s-0006N0-LC@sc8-sf-web22.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 12:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-08 23:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 07:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 02:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 12:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Wed May  9 15:40:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 06:40:48 -0700
Subject: [Patches] [ python-Patches-1715718 ] x64 clean compile patch for
	_ctypes
Message-ID: <E1HlmPQ-0004lP-Ou@sc8-sf-web22.sourceforge.net>

Patches item #1715718, was opened at 2007-05-09 13:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1715718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kristj?n Valur (krisvale)
Assigned to: Thomas Heller (theller)
Summary: x64 clean compile patch for _ctypes

Initial Comment:
A patch to make _ctypes compile cleanly on x64.  Mostly it is about changing int to Py_ssize_t where appropriate.

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

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

From noreply at sourceforge.net  Wed May  9 16:44:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 07:44:46 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HlnPK-0008I0-A9@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 08:18:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 09 May 2007 23:18:11 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hm1yd-0006WW-6r@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 12:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 23:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 07:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-08 23:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 07:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 02:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 12:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 13:56:51 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 04:56:51 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hm7GN-0007nU-D4@sc8-sf-web22.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 19:13
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: jos (josm)
Date: 2007-05-10 11:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 06:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 14:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 06:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 09:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 19:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 14:31:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 05:31:02 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1Hm7nS-0004nc-5j@sc8-sf-web23.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May 10 16:13:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 07:13:11 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hm9OJ-0000oq-CJ@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 16:13:38 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 07:13:38 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hm9Ok-0007aQ-FR@sc8-sf-web23.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 17:09:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 08:09:18 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HmAGc-0000WI-US@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May 10 23:37:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 14:37:40 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HmGKS-0000wr-O3@sc8-sf-web24.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 19:13
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: jos (josm)
Date: 2007-05-10 21:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 11:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 06:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 14:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 06:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 09:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 19:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 23:41:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 14:41:56 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HmGOa-0001Pn-Ul@sc8-sf-web24.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 17:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 17:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Thu May 10 23:52:24 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 14:52:24 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HmGYi-0002ay-DI@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Fri May 11 00:16:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 15:16:11 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HmGvj-0005Ck-Q4@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Fri May 11 07:14:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 22:14:11 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HmNSF-0005uI-M0@sc8-sf-web23.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 14:41
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alessio G. B. (wpy)
Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 01:14

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Issues:

0) The patch does not apply cleanly; please update it.
1) The patch is incorrect. It does not address the fact that compiling a
2-arg assert statement emits "RAISE_VARARGS 2".
2) The patch is spectacularly untested: because of (1), the interpreter
crashes almost immediately when running regrtest.py.
3) Even if you fix (1), the patch is not refcount-correct: regrtest.py
crashes after test_dict due to a refcounting error.

Also: the patch implements the "e.__traceback__ = T" implicit assignment.
The last I knew, there had never been a formal decision on whether to go
ahead with that part of the PEP (there having been quite an uproar and
whatnot). Guido: we may have kicked this particular can as far down the
road as it's going to go. As soon as we come to a final decision on this, I
have a tested, refcount-safe implementation that I'll put up on SF.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-08 10:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 13:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 13:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Fri May 11 07:24:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 10 May 2007 22:24:55 -0700
Subject: [Patches] [ python-Patches-1677694 ] test_timeout refactoring
Message-ID: <E1HmNcd-0000hw-ME@sc8-sf-web22.sourceforge.net>

Patches item #1677694, was opened at 2007-03-09 19:49
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677694&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bj?rn Lindqvist (sonderblade)
>Assigned to: Collin Winter (collinwinter)
Summary: test_timeout refactoring

Initial Comment:
Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470

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

Comment By: Bj?rn Lindqvist (sonderblade)
Date: 2007-03-10 09:39

Message:
Logged In: YES 
user_id=51702
Originator: YES

But the bugfix is so simple. :) The original author Dmitry Vasiliev
claimed that connecting to www.google.com with port 80 did not always work
for him because of a transparent proxy. I believe what he meant was that
connection was not guaranteed to timeout. So he changed the port to 21
which www.google.com does not respond to.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-03-09 22:39

Message:
Logged In: YES 
user_id=1344176
Originator: NO

In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it
fixes a bug which (I think) only happens when you access the internet from
behind a web proxy." Could you split any bug fixes into a patch separate
from the code cleanup and refactoring? That will make reviewing it/them
easier.

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

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

From noreply at sourceforge.net  Fri May 11 11:24:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 02:24:28 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HmRMS-0004X2-5n@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 20:41
Message generated for change (Comment added) made by wpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alessio G. B. (wpy)
Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Alessio G. B. (wpy)
Date: 2007-05-11 11:24

Message:
Logged In: YES 
user_id=1373701
Originator: YES

OK, today I will work on this problems.
I hope to release a new patch in short time.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 07:14

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Issues:

0) The patch does not apply cleanly; please update it.
1) The patch is incorrect. It does not address the fact that compiling a
2-arg assert statement emits "RAISE_VARARGS 2".
2) The patch is spectacularly untested: because of (1), the interpreter
crashes almost immediately when running regrtest.py.
3) Even if you fix (1), the patch is not refcount-correct: regrtest.py
crashes after test_dict due to a refcounting error.

Also: the patch implements the "e.__traceback__ = T" implicit assignment.
The last I knew, there had never been a formal decision on whether to go
ahead with that part of the PEP (there having been quite an uproar and
whatnot). Guido: we may have kicked this particular can as far down the
road as it's going to go. As soon as we come to a final decision on this, I
have a tested, refcount-safe implementation that I'll put up on SF.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 02:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-08 16:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 19:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 19:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Fri May 11 12:04:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 03:04:42 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HmRzO-0002uj-2M@sc8-sf-web21.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 21:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Georg Brandl (gbrandl)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 10:04

Message:
Logged In: YES 
user_id=849994
Originator: YES

I've fixed parsermodule.c.

Shall I check it in now? (On py3k-dev, you only said you're leaning
towards accepting it...)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 00:17

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hold on, test_parser started failing for me.  Things like this (lots of
variations):

======================================================================
FAIL: test_assert (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 176, in test_assert
    self.check_suite("assert alo < ahi and blo < bhi\n")
  File "Lib/test/test_parser.py", line 28, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 19, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'assert alo < ahi and blo < bhi\n':
illegal assert statement


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 00:09

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks good.  I'm accepting PEP and patch.  Check it in already!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 21:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Fri May 11 13:05:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:05:12 -0700
Subject: [Patches] [ python-Patches-1714700 ] os.linesep needs clarification
Message-ID: <E1HmSvw-0001EG-4v@sc8-sf-web21.sourceforge.net>

Patches item #1714700, was opened at 2007-05-08 02:54
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1714700&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.linesep needs clarification

Initial Comment:
On bug #1714381 (and in a message on a local Python list), people were trying to write a text file in this "portable" way:

f = open("filename","w")
f.write("Text" + os.linesep)
f.close()

Of course this is wrong, because the "portable" line terminator is just "\n", which gets converted into os.linesep by the C runtime library.

This patch adds a warning to the os.linesep documentation (and fixes a misplaced line break).


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:05

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, committed in rev. 55257, 55258.

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

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-08 02:58

Message:
Logged In: YES 
user_id=479790
Originator: YES

File Added: oslinesep.diff

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

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

From noreply at sourceforge.net  Fri May 11 13:10:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:10:16 -0700
Subject: [Patches] [ python-Patches-1698951 ] Bastion and rexec message
	out-of-date
Message-ID: <E1HmT0q-0001nk-BV@sc8-sf-web21.sourceforge.net>

Patches item #1698951, was opened at 2007-04-12 06:17
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1698951&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Georg Brandl (gbrandl)
Summary: Bastion and rexec message out-of-date

Initial Comment:
Bastion and rexec are disabled since version 2.2. They raise a RuntimeError, but the error message is a bit outdated (it says "...in Python 2.2 and 2.3")
Someone asked in c.l.p if those modules were now available again - the error message may have induced that perception, at least partially.

This patch just changes the message to say "...in Python 2.2 and later"


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:10

Message:
Logged In: YES 
user_id=849994
Originator: NO

Backported in rev 54903.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-04-12 07:01

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed in trunk rev. 54784. Will backport to 2.5 branch when it is
unfrozen.

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

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

From noreply at sourceforge.net  Fri May 11 13:38:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 04:38:50 -0700
Subject: [Patches] [ python-Patches-1667860 ] urllib2 raises an
	UnboundLocalError if "auth-int" is the qop
Message-ID: <E1HmTSU-0003ie-4o@sc8-sf-web24.sourceforge.net>

Patches item #1667860, was opened at 2007-02-24 15:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Atul Varma (varmaa)
Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 raises an UnboundLocalError if "auth-int" is the qop

Initial Comment:
If a proxy server is connected to that specifies the "auth-int" quality of protection (qop) code--or any qop code aside from "auth", actually--urllib2 raises an UnboundLocalError exception.  While this patch doesn't implement auth-int, it does modify the behavior of urllib2 such that it raises a URLError with the reason "qop '%s' is not supported', where %s is the name of the qop code.

Two unit tests that test urllib2's functionality with an in-process proxy can be found at:

  http://varmaa.googlepages.com/Urllib2ProxyTests.py

I will try to attach this file to this patch ticket if I can.  I am also interested in integrating this unit testing suite with the Python standard lib unit tests, and am willing to work with you if this is desirable.  One of the unit tests in this suite succeeds with the standard version of urllib2.py, but the other fails unless this patch is applied.

This patch (and the unit test suite) applies to Python 2.4 and 2.5.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:38

Message:
Logged In: YES 
user_id=849994
Originator: NO

I get this error with the newest test file:

test_urllib2_localnet
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 222, in
handle_request
    self.process_request(request, client_address)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 241, in
process_request
    self.finish_request(request, client_address)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 254, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 523, in
__init__
    self.handle()
  File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 316, in
handle
    self.handle_one_request()
  File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 310, in
handle_one_request
    method()
  File "/home/gbr/devel/python/Lib/test/test_urllib2_localnet.py", line
220, in do_GET
    self.wfile.write("Our apologies, but our server is down due to "
  File "/home/gbr/devel/python/Lib/socket.py", line 263, in write
    self.flush()
  File "/home/gbr/devel/python/Lib/socket.py", line 250, in flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')
test test_urllib2_localnet produced unexpected output:
**********************************************************************
*** lines 2-4 of actual output doesn't appear in expected output after
line 1:
+ ----------------------------------------
+ Exception happened during processing of request from ('127.0.0.1',
33141)
+ ----------------------------------------
**********************************************************************
1 test failed:
    test_urllib2_localnet


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

Comment By: Atul Varma (varmaa)
Date: 2007-04-14 21:27

Message:
Logged In: YES 
user_id=863202
Originator: YES

Sorry for the delay; I've added two failure cases to the testing
suite--one which supplies bad password information and another that has no
password information to supply--so the patch should now be complete. 
Please let me know if you need anything else.

File Added: test_urllib2_localnet.py

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 08:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

The new test file looks good, so if you complete the patch I'll apply it.

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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:42

Message:
Logged In: YES 
user_id=863202
Originator: YES

Thanks for the feedback, John--I've applied your suggestions to the
testing suite (including renaming the file name) and the patch file.  The
only thing I haven't done yet is add tests for failure cases, but I wanted
to submit the "refactored" version of the test suite before doing that so I
know I'm on the right track.


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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:38

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: test_urllib2_localnet.py

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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:33

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: urllib2_patch.diff

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

Comment By: John J Lee (jjlee)
Date: 2007-02-25 17:37

Message:
Logged In: YES 
user_id=261020
Originator: NO

This looks useful.

It would be nice to test failure cases too (e.g. wrong password,
.add_password() not called, ...).

I think if this goes into a new file (which might be reasonable), it
should be named something like test_urllib2_localnet.py , to allow for
adding more loopback tests, which will not always involve proxy handling. 
I suppose it should NOT depend on the network resource flag
(Lib/test/regrtest.py -u network) since it's only localhost.

Style (see PEP 8):

Don't put whitespace inside brackets -- e.g. bad: fn( arg ) good: fn(arg)

Use this_kind_of_name or thiskind if short, not thisKind.

Imports and classes etc. don't need comments to label them as such. 
Probably is useful to label the BaseHTTPServer code though (maybe '# Local
proxy test infrastructure').

See e.g. end of Lib/test/test_urllib2net.py for appropriate stdlib test
boilerplate.

Your patch has inconsistent line endings, BTW.


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

Comment By: Atul Varma (varmaa)
Date: 2007-02-24 15:20

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: Urllib2ProxyTests.py

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

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

From noreply at sourceforge.net  Fri May 11 14:38:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 05:38:32 -0700
Subject: [Patches] [ python-Patches-1717170 ] "Really  print?" Dialog
Message-ID: <E1HmUOG-0000FW-S3@sc8-sf-web22.sourceforge.net>

Patches item #1717170, was opened at 2007-05-11 15:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1717170&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Really  print?" Dialog

Initial Comment:
Currently, hitting the keyboard shortcut for the Print command sends whatever is in the current window to be printed. This happens by accident often enough to be a significant annoyance.

This simple patch to IOBinding.py makes the print command pop up a simple yes/no dialog which asks "Are you sure you want to print the window's contents?".

Some colleagues and I have been using this for several months to our satisfaction. It has saved me from printing by accident 3 times already.

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

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

From noreply at sourceforge.net  Fri May 11 14:39:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 05:39:02 -0700
Subject: [Patches] [ python-Patches-1717170 ] "Really  print?" Dialog
Message-ID: <E1HmUOk-0000JZ-21@sc8-sf-web22.sourceforge.net>

Patches item #1717170, was opened at 2007-05-11 15:38
Message generated for change (Settings changed) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1717170&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Really  print?" Dialog

Initial Comment:
Currently, hitting the keyboard shortcut for the Print command sends whatever is in the current window to be printed. This happens by accident often enough to be a significant annoyance.

This simple patch to IOBinding.py makes the print command pop up a simple yes/no dialog which asks "Are you sure you want to print the window's contents?".

Some colleagues and I have been using this for several months to our satisfaction. It has saved me from printing by accident 3 times already.

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

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

From noreply at sourceforge.net  Fri May 11 16:16:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 07:16:08 -0700
Subject: [Patches] [ python-Patches-1708353 ] Make isinstance/issubclass
	overloadable for PEP 3119
Message-ID: <E1HmVui-0005eN-VE@sc8-sf-web21.sourceforge.net>

Patches item #1708353, was opened at 2007-04-26 16:16
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1708353&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Make isinstance/issubclass overloadable for PEP 3119

Initial Comment:
I came up with a fairly simple way to overload isinstance() and issubclass().  The class that is the second argument can define a (class) method named __instancecheck__ or __subclasscheck__ which, if present, will be called *instead* of the normal approach.

The names are different to remind users that the calling convention is the opposite -- isinstance(x, C) maps to C.__instancecheck__(x).


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 10:16

Message:
Logged In: YES 
user_id=6380
Originator: YES

Version 3 compiles with older C89 compilers like gcc 2.96.
File Added: typechecks.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 17:27

Message:
Logged In: YES 
user_id=6380
Originator: YES

I'll add a description and motivation for this to PEP 3119.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 16:34

Message:
Logged In: YES 
user_id=6380
Originator: YES

Oops, forget the first attempt; isinstance(Integer(), Integer) would be
False!  Now it's True, and more tests are added.
File Added: typechecks.diff

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

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

From noreply at sourceforge.net  Fri May 11 16:51:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 07:51:52 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HmWTI-00064C-1f@sc8-sf-web23.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 17:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Georg Brandl (gbrandl)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 10:51

Message:
Logged In: YES 
user_id=6380
Originator: NO

Plese do!

And please mark the PEP as accepted and post a small item about it on the
py3k list.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 06:04

Message:
Logged In: YES 
user_id=849994
Originator: YES

I've fixed parsermodule.c.

Shall I check it in now? (On py3k-dev, you only said you're leaning
towards accepting it...)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:17

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hold on, test_parser started failing for me.  Things like this (lots of
variations):

======================================================================
FAIL: test_assert (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 176, in test_assert
    self.check_suite("assert alo < ahi and blo < bhi\n")
  File "Lib/test/test_parser.py", line 28, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 19, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'assert alo < ahi and blo < bhi\n':
illegal assert statement


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:09

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks good.  I'm accepting PEP and patch.  Check it in already!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 17:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Fri May 11 17:07:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 08:07:05 -0700
Subject: [Patches] [ python-Patches-1667860 ] urllib2 raises an
	UnboundLocalError if "auth-int" is the qop
Message-ID: <E1HmWi1-0001Ge-T1@sc8-sf-web24.sourceforge.net>

Patches item #1667860, was opened at 2007-02-24 15:19
Message generated for change (Comment added) made by varmaa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Atul Varma (varmaa)
Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 raises an UnboundLocalError if "auth-int" is the qop

Initial Comment:
If a proxy server is connected to that specifies the "auth-int" quality of protection (qop) code--or any qop code aside from "auth", actually--urllib2 raises an UnboundLocalError exception.  While this patch doesn't implement auth-int, it does modify the behavior of urllib2 such that it raises a URLError with the reason "qop '%s' is not supported', where %s is the name of the qop code.

Two unit tests that test urllib2's functionality with an in-process proxy can be found at:

  http://varmaa.googlepages.com/Urllib2ProxyTests.py

I will try to attach this file to this patch ticket if I can.  I am also interested in integrating this unit testing suite with the Python standard lib unit tests, and am willing to work with you if this is desirable.  One of the unit tests in this suite succeeds with the standard version of urllib2.py, but the other fails unless this patch is applied.

This patch (and the unit test suite) applies to Python 2.4 and 2.5.


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

>Comment By: Atul Varma (varmaa)
Date: 2007-05-11 15:07

Message:
Logged In: YES 
user_id=863202
Originator: YES

Ack, sorry about that Georg--I'll investigate and fix this over the
weekend.


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 11:38

Message:
Logged In: YES 
user_id=849994
Originator: NO

I get this error with the newest test file:

test_urllib2_localnet
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 222, in
handle_request
    self.process_request(request, client_address)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 241, in
process_request
    self.finish_request(request, client_address)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 254, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/gbr/devel/python/Lib/SocketServer.py", line 523, in
__init__
    self.handle()
  File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 316, in
handle
    self.handle_one_request()
  File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 310, in
handle_one_request
    method()
  File "/home/gbr/devel/python/Lib/test/test_urllib2_localnet.py", line
220, in do_GET
    self.wfile.write("Our apologies, but our server is down due to "
  File "/home/gbr/devel/python/Lib/socket.py", line 263, in write
    self.flush()
  File "/home/gbr/devel/python/Lib/socket.py", line 250, in flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')
test test_urllib2_localnet produced unexpected output:
**********************************************************************
*** lines 2-4 of actual output doesn't appear in expected output after
line 1:
+ ----------------------------------------
+ Exception happened during processing of request from ('127.0.0.1',
33141)
+ ----------------------------------------
**********************************************************************
1 test failed:
    test_urllib2_localnet


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

Comment By: Atul Varma (varmaa)
Date: 2007-04-14 21:27

Message:
Logged In: YES 
user_id=863202
Originator: YES

Sorry for the delay; I've added two failure cases to the testing
suite--one which supplies bad password information and another that has no
password information to supply--so the patch should now be complete. 
Please let me know if you need anything else.

File Added: test_urllib2_localnet.py

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-13 08:08

Message:
Logged In: YES 
user_id=849994
Originator: NO

The new test file looks good, so if you complete the patch I'll apply it.

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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:42

Message:
Logged In: YES 
user_id=863202
Originator: YES

Thanks for the feedback, John--I've applied your suggestions to the
testing suite (including renaming the file name) and the patch file.  The
only thing I haven't done yet is add tests for failure cases, but I wanted
to submit the "refactored" version of the test suite before doing that so I
know I'm on the right track.


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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:38

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: test_urllib2_localnet.py

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

Comment By: Atul Varma (varmaa)
Date: 2007-02-26 01:33

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: urllib2_patch.diff

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

Comment By: John J Lee (jjlee)
Date: 2007-02-25 17:37

Message:
Logged In: YES 
user_id=261020
Originator: NO

This looks useful.

It would be nice to test failure cases too (e.g. wrong password,
.add_password() not called, ...).

I think if this goes into a new file (which might be reasonable), it
should be named something like test_urllib2_localnet.py , to allow for
adding more loopback tests, which will not always involve proxy handling. 
I suppose it should NOT depend on the network resource flag
(Lib/test/regrtest.py -u network) since it's only localhost.

Style (see PEP 8):

Don't put whitespace inside brackets -- e.g. bad: fn( arg ) good: fn(arg)

Use this_kind_of_name or thiskind if short, not thisKind.

Imports and classes etc. don't need comments to label them as such. 
Probably is useful to label the BaseHTTPServer code though (maybe '# Local
proxy test infrastructure').

See e.g. end of Lib/test/test_urllib2net.py for appropriate stdlib test
boilerplate.

Your patch has inconsistent line endings, BTW.


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

Comment By: Atul Varma (varmaa)
Date: 2007-02-24 15:20

Message:
Logged In: YES 
user_id=863202
Originator: YES

File Added: Urllib2ProxyTests.py

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

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

From noreply at sourceforge.net  Fri May 11 17:08:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 08:08:28 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HmWjM-0008Hy-9g@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 20:41
Message generated for change (Comment added) made by wpy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alessio G. B. (wpy)
Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Alessio G. B. (wpy)
Date: 2007-05-11 17:08

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have corrected the patch.

1) In the patch, I would to put also the modifications to
.py files of distribution? I don't thought... So the patch become very
big!!!
If you want, I do it.
The patch concerns to implementation (C source files) only!...

2) In the new patch I dropped the code for "__traceback__ part" of
the PEP 3109. Therefore, after application of the fix_raise.py script to
library some modules not works whatever.
File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-11 11:24

Message:
Logged In: YES 
user_id=1373701
Originator: YES

OK, today I will work on this problems.
I hope to release a new patch in short time.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 07:14

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Issues:

0) The patch does not apply cleanly; please update it.
1) The patch is incorrect. It does not address the fact that compiling a
2-arg assert statement emits "RAISE_VARARGS 2".
2) The patch is spectacularly untested: because of (1), the interpreter
crashes almost immediately when running regrtest.py.
3) Even if you fix (1), the patch is not refcount-correct: regrtest.py
crashes after test_dict due to a refcounting error.

Also: the patch implements the "e.__traceback__ = T" implicit assignment.
The last I knew, there had never been a formal decision on whether to go
ahead with that part of the PEP (there having been quite an uproar and
whatnot). Guido: we may have kicked this particular can as far down the
road as it's going to go. As soon as we come to a final decision on this, I
have a tested, refcount-safe implementation that I'll put up on SF.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 02:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-08 16:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 19:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 19:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Fri May 11 17:35:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 08:35:47 -0700
Subject: [Patches] [ python-Patches-1711529 ] PEP 3132: extended unpacking
Message-ID: <E1HmX9n-000327-S3@sc8-sf-web22.sourceforge.net>

Patches item #1711529, was opened at 2007-05-02 21:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711529&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Georg Brandl (gbrandl)
Assigned to: Georg Brandl (gbrandl)
Summary: PEP 3132: extended unpacking

Initial Comment:
Implements PEP 3132.

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 15:35

Message:
Logged In: YES 
user_id=849994
Originator: YES

Done in rev. 55262.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 14:51

Message:
Logged In: YES 
user_id=6380
Originator: NO

Plese do!

And please mark the PEP as accepted and post a small item about it on the
py3k list.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-11 10:04

Message:
Logged In: YES 
user_id=849994
Originator: YES

I've fixed parsermodule.c.

Shall I check it in now? (On py3k-dev, you only said you're leaning
towards accepting it...)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 00:17

Message:
Logged In: YES 
user_id=6380
Originator: NO

Hold on, test_parser started failing for me.  Things like this (lots of
variations):

======================================================================
FAIL: test_assert (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 176, in test_assert
    self.check_suite("assert alo < ahi and blo < bhi\n")
  File "Lib/test/test_parser.py", line 28, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 19, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'assert alo < ahi and blo < bhi\n':
illegal assert statement


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-09 00:09

Message:
Logged In: YES 
user_id=6380
Originator: NO

Looks good.  I'm accepting PEP and patch.  Check it in already!

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-02 21:33

Message:
Logged In: YES 
user_id=849994
Originator: YES

Version 2 adds a helpful source code comment and one new test.
File Added: extended_unpack_3.diff

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

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

From noreply at sourceforge.net  Fri May 11 18:40:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 09:40:37 -0700
Subject: [Patches] [ python-Patches-1713889 ] Patch for PEP 3109
Message-ID: <E1HmYAX-0001qe-JW@sc8-sf-web22.sourceforge.net>

Patches item #1713889, was opened at 2007-05-06 14:41
Message generated for change (Comment added) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alessio G. B. (wpy)
Assigned to: Collin Winter (collinwinter)
Summary: Patch for PEP 3109

Initial Comment:
The patch modify the raise statement, according to PEP
3109 and script fix_raise.py (available in sandbox 
directory of SVN).
Compile all ok, but it's not complete: now, exiting from 
Python interpreter, there is Segmentation fault.
I think to work on this problem in next days.

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

>Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 12:40

Message:
Logged In: YES 
user_id=1344176
Originator: NO

The patch to Python/compile.c is still obviously incorrect, even more so
than before. Try this:

>>> assert True is False
>>>

And of course, this little gem:

>>> assert True is False, "um really?"
Traceback (most recent call last):
TypeError: exceptions must derive from BaseException
>>>

Your unwillingness, inability or disinclination to properly test your
patch is wasting my time.

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-11 11:08

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have corrected the patch.

1) In the patch, I would to put also the modifications to
.py files of distribution? I don't thought... So the patch become very
big!!!
If you want, I do it.
The patch concerns to implementation (C source files) only!...

2) In the new patch I dropped the code for "__traceback__ part" of
the PEP 3109. Therefore, after application of the fix_raise.py script to
library some modules not works whatever.
File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-11 05:24

Message:
Logged In: YES 
user_id=1373701
Originator: YES

OK, today I will work on this problems.
I hope to release a new patch in short time.

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

Comment By: Collin Winter (collinwinter)
Date: 2007-05-11 01:14

Message:
Logged In: YES 
user_id=1344176
Originator: NO

Issues:

0) The patch does not apply cleanly; please update it.
1) The patch is incorrect. It does not address the fact that compiling a
2-arg assert statement emits "RAISE_VARARGS 2".
2) The patch is spectacularly untested: because of (1), the interpreter
crashes almost immediately when running regrtest.py.
3) Even if you fix (1), the patch is not refcount-correct: regrtest.py
crashes after test_dict due to a refcounting error.

Also: the patch implements the "e.__traceback__ = T" implicit assignment.
The last I knew, there had never been a formal decision on whether to go
ahead with that part of the PEP (there having been quite an uproar and
whatnot). Guido: we may have kicked this particular can as far down the
road as it's going to go. As soon as we come to a final decision on this, I
have a tested, refcount-safe implementation that I'll put up on SF.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-08 20:10

Message:
Logged In: YES 
user_id=6380
Originator: NO

Collin, can you review this?

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-08 10:12

Message:
Logged In: YES 
user_id=1373701
Originator: YES

I have correct all errors.

I hope that it is useful.
File Added: pep3109.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 13:56

Message:
Logged In: YES 
user_id=1373701
Originator: YES

File Added: pep3109-2.patch

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

Comment By: Alessio G. B. (wpy)
Date: 2007-05-07 13:06

Message:
Logged In: YES 
user_id=1373701
Originator: YES

With compiler (GCC) options "-g3 -ggdb3" there isn't Segmentation fault.
With default option "-g" yes....

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

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

From noreply at sourceforge.net  Fri May 11 18:49:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 09:49:03 -0700
Subject: [Patches] [ python-Patches-1704474 ] test_optparse.py mod. for
	jython
Message-ID: <E1HmYIh-0002Fn-QW@sc8-sf-web21.sourceforge.net>

Patches item #1704474, was opened at 2007-04-20 12:50
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704474&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Couper (drtimcouper)
>Assigned to: Greg Ward (gward)
Summary: test_optparse.py mod. for jython

Initial Comment:
Extension of test code for jython

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

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

From noreply at sourceforge.net  Fri May 11 23:40:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 11 May 2007 14:40:26 -0700
Subject: [Patches] [ python-Patches-1708353 ] Make isinstance/issubclass
	overloadable for PEP 3119
Message-ID: <E1Hmcqg-0007bZ-Us@sc8-sf-web23.sourceforge.net>

Patches item #1708353, was opened at 2007-04-26 16:16
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1708353&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Make isinstance/issubclass overloadable for PEP 3119

Initial Comment:
I came up with a fairly simple way to overload isinstance() and issubclass().  The class that is the second argument can define a (class) method named __instancecheck__ or __subclasscheck__ which, if present, will be called *instead* of the normal approach.

The names are different to remind users that the calling convention is the opposite -- isinstance(x, C) maps to C.__instancecheck__(x).


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 17:40

Message:
Logged In: YES 
user_id=6380
Originator: YES

FWIW, this can run into unchecked infinite recursion easily:

class C:
    # There's no @classmethod decorator here as there should have been
    def __instancecheck__(self, arg):
        return False

isinstance(42, C)

The reason is that on line 372 in classobject.c there's a call to
PyObject_IsInstance(self, klass).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 10:16

Message:
Logged In: YES 
user_id=6380
Originator: YES

Version 3 compiles with older C89 compilers like gcc 2.96.
File Added: typechecks.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 17:27

Message:
Logged In: YES 
user_id=6380
Originator: YES

I'll add a description and motivation for this to PEP 3119.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 16:34

Message:
Logged In: YES 
user_id=6380
Originator: YES

Oops, forget the first attempt; isinstance(Integer(), Integer) would be
False!  Now it's True, and more tests are added.
File Added: typechecks.diff

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

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

From noreply at sourceforge.net  Sat May 12 16:09:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 07:09:49 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HmsI9-0004Oq-Qb@sc8-sf-web24.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 19:13
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: jos (josm)
Date: 2007-05-12 14:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 21:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 21:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 11:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 06:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 14:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 06:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 09:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 19:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Sat May 12 21:27:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 12:27:25 -0700
Subject: [Patches] [ python-Patches-1708353 ] Make isinstance/issubclass
	overloadable for PEP 3119
Message-ID: <E1HmxFV-0003Au-Gi@sc8-sf-web23.sourceforge.net>

Patches item #1708353, was opened at 2007-04-26 20:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1708353&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Make isinstance/issubclass overloadable for PEP 3119

Initial Comment:
I came up with a fairly simple way to overload isinstance() and issubclass().  The class that is the second argument can define a (class) method named __instancecheck__ or __subclasscheck__ which, if present, will be called *instead* of the normal approach.

The names are different to remind users that the calling convention is the opposite -- isinstance(x, C) maps to C.__instancecheck__(x).


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-12 19:27

Message:
Logged In: YES 
user_id=849994
Originator: NO

Probably a warning would be good for the non-classmethod case.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 21:40

Message:
Logged In: YES 
user_id=6380
Originator: YES

FWIW, this can run into unchecked infinite recursion easily:

class C:
    # There's no @classmethod decorator here as there should have been
    def __instancecheck__(self, arg):
        return False

isinstance(42, C)

The reason is that on line 372 in classobject.c there's a call to
PyObject_IsInstance(self, klass).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 14:16

Message:
Logged In: YES 
user_id=6380
Originator: YES

Version 3 compiles with older C89 compilers like gcc 2.96.
File Added: typechecks.diff

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 21:27

Message:
Logged In: YES 
user_id=6380
Originator: YES

I'll add a description and motivation for this to PEP 3119.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 20:34

Message:
Logged In: YES 
user_id=6380
Originator: YES

Oops, forget the first attempt; isinstance(Integer(), Integer) would be
False!  Now it's True, and more tests are added.
File Added: typechecks.diff

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

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

From noreply at sourceforge.net  Sat May 12 23:18:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 14:18:58 -0700
Subject: [Patches] [ python-Patches-1650090 ] doctest doesn't find nested
	functions
Message-ID: <E1HmyzS-0001Lk-3L@sc8-sf-web22.sourceforge.net>

Patches item #1650090, was opened at 2007-02-01 19:20
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1650090&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Brown (danb37)
Assigned to: Tim Peters (tim_one)
Summary: doctest doesn't find nested functions

Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
  '''
  >>> 'a'
  'a'
  '''

  def g():
    '''
    >>> 'a'
    'b'
    '''
    pass

  pass
}}}

DocTestFinder will only find f's doctest and won't recurse to find g's, surprising the programmer when they (hopefully) discover that their inner doctest is incorrect!

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-03-17 00:37

Message:
Logged In: YES 
user_id=1326842
Originator: NO

Here is a patch that implements this new functionality.
I don't know how desireable this feature is, I just
wanted to see if it could be done.
File Added: doctest_nested_functions.diff

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

Comment By: Piet Delport (pjdelport)
Date: 2007-03-16 20:44

Message:
Logged In: YES 
user_id=1607528
Originator: NO

DocTestFinder uses object inspection to find docstrings, which doesn't
really allow this kind of thing:  g isn't created until f is actually run.

Making this possible would probably require implementing an alternate
doctest finder based on source code inspection (via the new _ast module?).

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

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

From noreply at sourceforge.net  Sat May 12 23:23:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 14:23:48 -0700
Subject: [Patches] [ python-Patches-1490190 ] add os.chflags() and
	os.lchflags() where available
Message-ID: <E1Hmz48-0001uL-5i@sc8-sf-web22.sourceforge.net>

Patches item #1490190, was opened at 2006-05-17 11:45
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490190&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.5
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: M. Levinson (levinsm)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: add os.chflags() and os.lchflags() where available

Initial Comment:
The return value from os.stat() includes st_flags on some systems, but
currently there's not much that can be done with the value; this patch aims
to make st_flags useful by adding some associated constants to stat.py and
the corresponding chflags() and lchflags() functions in posixmodule. For
completeness, shutil.copystat() is also updated to call os.chflags() where
it's available.


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

Comment By: Martin v. L?wis (loewis)
Date: 2007-03-21 16:46

Message:
Logged In: YES 
user_id=21627
Originator: NO

nnorwitz, can you please report whether the attached patch fixes it?
File Added: chflags.diff

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-20 06:42

Message:
Logged In: YES 
user_id=33168
Originator: NO

It looks like Tru64 does have some version of chflags, however, it is
undocumented and apparently causes  python to exit.  It is at least one of
the reasons for the recent buildbot failures:

http://python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/1550/step-test/0

That doesn't really tell the whole story, but I logged on to the machine
and ran the test, after modifying unittest to flush the stream, sigh :-(
and got this:

ringneck:/net/cci/nnorwitz/python/trunk.norwitz-tru64/nn-work-build %
./python -E -tt ./Lib/test/regrtest.py -v test_posix
test_posix
testNoArgFunctions (test.test_posix.PosixTester) ... ok
test_access (test.test_posix.PosixTester) ... ok
test_chdir (test.test_posix.PosixTester) ... ok
test_chflags (test.test_posix.PosixTester) ... Bad system call


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

Comment By: Martin v. L?wis (loewis)
Date: 2007-02-19 10:56

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the patch. Committed as r53826.

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

Comment By: M. Levinson (levinsm)
Date: 2006-05-19 11:47

Message:
Logged In: YES 
user_id=1522893

In addition to MacOS, chflags(2) is available on FreeBSD,
OpenBSD, and
NetBSD. The flags in Lib/stat.py are the full set of
available values
although, as you noted, MacOS hasn't (yet) implemented
several of them.

Thanks for the comments - I've attached an updated version
of the patch
incorporating your suggestions.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-19 07:31

Message:
Logged In: YES 
user_id=33168

What operating systems is this available on?  The only one
I've found is OS X.  The man page says it's from BSD 4.4.  I
tried on Linux of various flavors (4+), Solaris, and Tru64.
 None of them had chflags.  I also could only find some of
the flags in my sys/stat.h that were added to stat.py. 
stat.h didn't have UF_NOUNLINK, SF_NOUNLINK, SF_SNAPSHOT.

As far as the patch itself, it looks good.  There are a
couple of changes if this should be accepted though:  doc
needs \versionadded{2.5}, I would prefer flags as the var
name rather than i in posixmodule.c (btw you shouldn't need
to init path).

Also would need to update Misc/NEWS and ACKS if accepted.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-17 14:24

Message:
Logged In: YES 
user_id=849994

Patch looks good. Do we want to include it?

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

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

From noreply at sourceforge.net  Sun May 13 05:09:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 12 May 2007 20:09:25 -0700
Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter
	Unpacking [PEP3113]
Message-ID: <E1Hn4Sb-0003LY-Uu@sc8-sf-web24.sourceforge.net>

Patches item #1678060, was opened at 2007-03-10 13:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tony Lownds (tonylownds)
Assigned to: Brett Cannon (bcannon)
Summary: Removal of Tuple Parameter Unpacking [PEP3113]

Initial Comment:
Remove tuple parameter unpacking. The Grammar is now:

typedargslist: ((tfpdef ['=' test] ',')*
                ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef)
                | tfpdef ['=' test] (',' tfpdef ['=' test])* [','])
tfpdef: NAME [':' test]
varargslist: ((vfpdef ['=' test] ',')*
              ('*' [vfpdef] (',' vfpdef ['=' test])*  [',' '**' vfpdef] | '**' vfpdef)
              | vfpdef ['=' test] (',' vfpdef ['=' test])* [','])
vfpdef: NAME

Tuple parameters are removed from Lib/.

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

>Comment By: Brett Cannon (bcannon)
Date: 2007-05-12 20:09

Message:
Logged In: YES 
user_id=357491
Originator: NO

I have uploaded the current patch I am working off of.  Basically the only
difference is a style choice of not having parentheses in automatic
unpacking.  I also kept a method in the compiler package that was slated to
be removed.

But as of r55280, test_compiler and test_transformer are failing.  I don't
know the compiler package at all, so if you can have a look, Tony, I would
really appreciate it.
File Added: latest.diff

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

Comment By: Brett Cannon (bcannon)
Date: 2007-05-04 22:08

Message:
Logged In: YES 
user_id=357491
Originator: NO

Just so that Tony knows, this patch is next on my TODO list for Python. 
And I will be reviewing your patch instead of doing a blind 2to3
translation.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-23 09:30

Message:
Logged In: YES 
user_id=764593
Originator: NO

Brett,

2to3 is an important tool, but probably won't ever match good hand-work.

(1)  There are several places where he improved the code.

replacing map + an unpacking nested function with a generator:
"""
 def classify_class_attrs(object):
     """Wrap inspect.classify_class_attrs, with fixup for data
descriptors."""
-    def fixup((name, kind, cls, value)):
+    for (name, kind, cls, value) in
inspect.classify_class_attrs(object):
         if inspect.isdatadescriptor(value):
             kind = 'data descriptor'
-        return name, kind, cls, value
-    return map(fixup, inspect.classify_class_attrs(object))
+        yield name, kind, cls, value
"""


Replacing a paren-laden lambda with named function:
"""
-            items = sorted(items, key=lambda (k, v): (str(type(k)), k,
v))
+            def sortkey(item):
+                key, value = item
+                return str(type(key)), key, value
+            items = sorted(items, key=sortkey)
"""

Replacing filter + lambda + unpack with list comprehension:
"""
-        attrs = filter(lambda (name, kind, cls, value):
visiblename(name),
-                       classify_class_attrs(object))
+        attrs = [(name, kind, cls, value)
+                 for name, kind, cls, value in
classify_class_attrs(object)
+                 if visiblename(name)]
"""


(2)  His names are better.

I prefer his (name, result, expected)) over the current (name, (v1,v2),
(e1,e2))), let alone (name, _v1_v2_, _e1_e2_))

Even looking just at code with good existing names, he uses components
instead of _scheme_netloc_url_query_fragment_

So we get (what looks like human-readable source)

-def urlunsplit((scheme, netloc, url, query, fragment)):
+def urlunsplit(components):
+    (scheme, netloc, url, query, fragment) = components

instead of (what looks like the output of a computer translation step)

+def urlunsplit(_scheme_netloc_url_query_fragment_):
+    (scheme, netloc, url, query, fragment) =
_scheme_netloc_url_query_fragment_




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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 16:59

Message:
Logged In: YES 
user_id=357491
Originator: NO

The reason I mention using 2to3 is Collin has done a bunch of work on it
in order to make it also work with lambda.  I believe he also cleaned up
the generated names.

And as for cleaning up the patches, Tony, I can easily edit the diff file
manually, but thanks for the offer.  But if I need you to I will let you
know.

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-22 14:53

Message:
Logged In: YES 
user_id=24100
Originator: YES

Thanks for the comments.

Re: "stuff", if you look at other parts of the code, that is how the
triple is referred to -- fyi on how the name "stuff" came to be :) I was
also at a loss for a better name, and went with the contextual references.

Re: using 2to3 -- Brett, in many cases I actually tried to come up with a
consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like
that. Or it did when I last tried. Anyway, if you end up using 2to3, I
would really appreciate it if you also picked up the inspect.py docstring
change.

Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is
generated code, and that is why "repr" is used. I chose to change the
generation source rather than the generation machinery as I was changing
the source anyway, to account for the changes to parameter syntax. That is
why there are API changes. Given that other API changes were made and those
class constructors are more or less an internal API (created through
compiler.parse),
I believe this is the best way of dealing with the changes.

Brett, If you need me to remove the 2to3 doc toolchain patches, I can do
that.


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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 12:57

Message:
Logged In: YES 
user_id=357491
Originator: NO

Chances are I will take Tony's patch for its removal of the feature and
use 2to3 to handle the conversion as much as possible.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:57

Message:
Logged In: YES 
user_id=764593
Originator: NO

On the reprs, is there a reason to call repr instead of using %r?

For example, the Floordiv repr changed to:

"FloorDiv(%s, %s)" % (repr(self.left), repr(self.right))

Why not "FloorDiv(%r, %r)" % (self.left, self.right)

or even, (assuming PEP 3101 with locals,)

"FloorDiv({self.left:r}, {self.right:r})".format()

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:47

Message:
Logged In: YES 
user_id=764593
Originator: NO

Not sure if any of these are really problems, and it looks like Tony
already looked them over before submitting, but still worth mentioning...

(1)  This does more than take out tuples, though the other changes do also
look like things that ought to change for py3k.

(2)  I was amused by the name "stuff", but I couldn't think of a better
name for that particular grouping.  (suffix, mode, type)

(3)  There are some signature changes, where the unpacking is now done by
the caller, such as 

 class LeftShift(Node):
-    def __init__(self, (left, right), lineno=None):
+    def __init__(self, left, right, lineno=None):

(4)  The pdb change marks could be shortened a bit.  That shouldn't matter
for patching, but I'll post it here since it helped me.

-    def user_exception(self, frame, (exc_type, exc_value,
exc_traceback)):
+    def user_exception(self, frame, exc_info):
         """This function is called if an exception occurs,
         but only if we are to stop at or just below this level."""
+        (exc_type, exc_value, exc_traceback) = exc_info
         frame.f_locals['__exception__'] = exc_type, exc_value      
-        if type(exc_type) == type(''):
-            exc_type_name = exc_type
-        else: exc_type_name = exc_type.__name__
+        exc_type_name = exc_type.__name__
         print(exc_type_name + ':', _saferepr(exc_value),
file=self.stdout)
         self.interaction(frame, exc_traceback)


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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-12 08:07

Message:
Logged In: YES 
user_id=24100
Originator: YES

I found some more code to be removed + a docstring fix in inspect.py.
getfullargspec's docstring lists the 
wrong order for return values. This patch combined the refmanual patch,
previous simplified args patch, 
and 2to3 changes on some doc building tools.

File Added: simplified-args.patch

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-11 15:34

Message:
Logged In: YES 
user_id=24100
Originator: YES

File Added: refmanual.patch

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

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

From noreply at sourceforge.net  Sun May 13 10:27:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:27:53 -0700
Subject: [Patches] [ python-Patches-1718043 ] textView code cleanup
Message-ID: <E1Hn9Qn-00020W-KD@sc8-sf-web23.sourceforge.net>

Patches item #1718043, was opened at 2007-05-13 11:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718043&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: textView code cleanup

Initial Comment:
I refactored textView a bit:

1) Moved file/text logic out of the TextViewer class. The constructor is now called with the text to be shown, instead of being called with either a filename or text, which made calls to it ugly.

2) Moved duplicate logic found in TextViewer and aboutDialog.py into a utility function, textView.view_file.

3) Created new utility function, textView.view_text (also used by view_file).

4) Updated test code to test both utility functions.


Changed EditorWindow.py and aboutDialog.py to use these new utility functions (improved readability).

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

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

From noreply at sourceforge.net  Sun May 13 10:28:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:28:17 -0700
Subject: [Patches] [ python-Patches-1718043 ] textView code cleanup
Message-ID: <E1Hn9RB-00026b-86@sc8-sf-web23.sourceforge.net>

Patches item #1718043, was opened at 2007-05-13 11:27
Message generated for change (Settings changed) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718043&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: textView code cleanup

Initial Comment:
I refactored textView a bit:

1) Moved file/text logic out of the TextViewer class. The constructor is now called with the text to be shown, instead of being called with either a filename or text, which made calls to it ugly.

2) Moved duplicate logic found in TextViewer and aboutDialog.py into a utility function, textView.view_file.

3) Created new utility function, textView.view_text (also used by view_file).

4) Updated test code to test both utility functions.


Changed EditorWindow.py and aboutDialog.py to use these new utility functions (improved readability).

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

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

From noreply at sourceforge.net  Sun May 13 10:52:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 01:52:20 -0700
Subject: [Patches] [ python-Patches-1529018 ] Move firewall warning to
	"about" menu
Message-ID: <E1Hn9oS-0001Ao-1q@sc8-sf-web21.sourceforge.net>

Patches item #1529018, was opened at 2006-07-26 17:13
Message generated for change (Comment added) made by taleinat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529018&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Move firewall warning to "about" menu

Initial Comment:
This patch addresses the point brought up  in the
following post on IDLE-dev by Gregor Lingl. I support
this change and nobody raised an objection.

"
The firewall warning message in the Pythonshell window
was introduced  in Python 2.3 (IDLE 1.0 or something
similar?)

I remember well the problems, which have been occurred
then, and
to which it was the answer. (If I remember correctly I was
involved in the discussion thread which led to the
introduction
of that message.)

Since more than three years I've used IDLE on many
different
systems and I didn't encounter a single Firewall
warning since
then. (It seems that firewalls nowadays are not offended by
the use of 127.0.0.1)

Therefore, and because the message is long and ugly,
I'd like to
suggest to delete it from the Python Shell window
and - if considered necessary - for instance to put
it into the IDLE Help - "About IDLE" submenu or
in a special IDLE-Firewall warning submenu of IDLE-Help.

Please observe that it pops up thousands of times and it's
read at most once.

Additional remark (about my personal interest):
I have to do a lot of IDLE-screenshots for a textbook
on programming and I really don't like it to occur on
all those screenshots.
"

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

>Comment By: Tal Einat (taleinat)
Date: 2007-05-13 11:52

Message:
Logged In: YES 
user_id=1330769
Originator: YES

Updated (use newer patch file instead of the original):

* Uses new textView utility functions (see patch 1718043)
* Diff relative to Rev. 55290
File Added: IDLE_firewall_warning.070513.patch

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

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

From noreply at sourceforge.net  Sun May 13 13:56:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 04:56:13 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HnCgP-0003Fu-QJ@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 07:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, merely changing (fixing) the handling of "depth" parameter is not a
spec change. The patch makes pprint behave in a way that is intuitive from
the meaning of "depth".

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

Comment By: jos (josm)
Date: 2007-05-12 10:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 17:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 17:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Sun May 13 14:14:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 05:14:43 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HnCyJ-0007Hw-Fd@sc8-sf-web22.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 19:13
Message generated for change (Comment added) made by josm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

Comment By: jos (josm)
Date: 2007-05-13 12:14

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What is intuitive is a matter of taste.
Some people like to count from zero, like many programmers do.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 11:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, merely changing (fixing) the handling of "depth" parameter is not a
spec change. The patch makes pprint behave in a way that is intuitive from
the meaning of "depth".

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

Comment By: jos (josm)
Date: 2007-05-12 14:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 21:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 21:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 14:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 11:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 06:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 14:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 06:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 14:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 09:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 19:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From garcia_peter at msn.com  Sun May 13 15:50:14 2007
From: garcia_peter at msn.com (peter garcia)
Date: Sun, 13 May 2007 09:50:14 -0400
Subject: [Patches]   Best Price On Viagra - NO PRESCRIPTION NEEDED
Message-ID: <BAY115-DAV550FA84C2483D1599828DF33F0@phx.gbl>

Hello

I need to buy Devincal can you help?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20070513/24bc84c5/attachment.htm 

From noreply at sourceforge.net  Sun May 13 16:21:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 07:21:44 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1HnExE-00053O-Hi@sc8-sf-web24.sourceforge.net>

Patches item #1718153, was opened at 2007-05-13 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718153&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

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

From noreply at sourceforge.net  Sun May 13 17:09:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 13 May 2007 08:09:30 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HnFhS-0007hC-M5@sc8-sf-web21.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 11:09

Message:
Logged In: YES 
user_id=984087
Originator: YES

josm, please feel free to go to python-dev if you think community input is
required. I personally don't think that it is warranted.

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

Comment By: jos (josm)
Date: 2007-05-13 08:14

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What is intuitive is a matter of taste.
Some people like to count from zero, like many programmers do.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 07:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, merely changing (fixing) the handling of "depth" parameter is not a
spec change. The patch makes pprint behave in a way that is intuitive from
the meaning of "depth".

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

Comment By: jos (josm)
Date: 2007-05-12 10:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 17:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 17:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Mon May 14 21:12:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 12:12:49 -0700
Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache
	optimization updated for Python 2.6
Message-ID: <E1HnfyT-0003w4-Qx@sc8-sf-web21.sourceforge.net>

Patches item #1700288, was opened at 2007-04-13 19:16
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Jacobs (bioinformed)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Armin's method cache optimization updated for Python 2.6

Initial Comment:
I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986).  I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up.

My performance results are not quite as good as Armin's, though still very encouraging.  I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%.  Given these rather significant results, the major task is to verify correctness.


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

>Comment By: Armin Rigo (arigo)
Date: 2007-05-14 19:12

Message:
Logged In: YES 
user_id=4771
Originator: NO

A further minor improvement could be achieved by
re-doing the inlining of _PyType_Lookup() in
object.c.  Ideally, the fast path only could be
inlined, and the rest put in a separate function
or just using _PyType_Lookup().

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

Comment By: Kevin Jacobs (bioinformed)
Date: 2007-04-14 13:49

Message:
Logged In: YES 
user_id=1768698
Originator: YES

I benchmarked using pystone, pybench, and a bunch of my local scientific
applications that have tight computational kernels still in pure Python.  I
tested on a 64bit Linux box, defining the version_tag as either int or
unsigned long with no appreciable difference in performance.  I'm trying to
get parrotbench to run, but it doesn't seem to have been updated for modern
Python versions.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-14 06:21

Message:
Logged In: YES 
user_id=33168
Originator: NO

I tried this test on parrotbench (b0.py in particular) and I'm not sure I
could distinguish an improvement over the noise (best case was about 5%). 
The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc
4.1.2-ish).  At first it seemed a bit slower with the original patch which
uses unsigned ints.  I tried changing to unsigned longs.  It seemed a
little better, though not sure if it was really due to the change.  I think
unsigned longs should be used for 64-bit boxes.

Did you use a benchmark/program that is open source?  I don't know that I
have anything decent to test this with.  Raymond probably does though. 
Also what platform did you test on?

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

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

From noreply at sourceforge.net  Mon May 14 22:18:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 13:18:58 -0700
Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache
	optimization updated for Python 2.6
Message-ID: <E1Hnh0U-0006Dp-NE@sc8-sf-web22.sourceforge.net>

Patches item #1700288, was opened at 2007-04-13 15:16
Message generated for change (Comment added) made by bioinformed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Jacobs (bioinformed)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Armin's method cache optimization updated for Python 2.6

Initial Comment:
I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986).  I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up.

My performance results are not quite as good as Armin's, though still very encouraging.  I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%.  Given these rather significant results, the major task is to verify correctness.


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

>Comment By: Kevin Jacobs (bioinformed)
Date: 2007-05-14 16:18

Message:
Logged In: YES 
user_id=1768698
Originator: YES

I tried re-inlining the fast path from _PyType_Lookup() in object.c and
found no measurable improvement on the simple benchmarks I tried.  I've
also stress-tested the patch by disabling the fast-path return, always
performing the slow-path lookup, and asserting that the cached result
matches the slow-path result.  I then ran that modified interpreter on the
Python test-suite, various benchmarks, and a range of my own applications. 
While not a formal proof of correctness, it was encouraging that the cache
remained consistent.

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

Comment By: Armin Rigo (arigo)
Date: 2007-05-14 15:12

Message:
Logged In: YES 
user_id=4771
Originator: NO

A further minor improvement could be achieved by
re-doing the inlining of _PyType_Lookup() in
object.c.  Ideally, the fast path only could be
inlined, and the rest put in a separate function
or just using _PyType_Lookup().

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

Comment By: Kevin Jacobs (bioinformed)
Date: 2007-04-14 09:49

Message:
Logged In: YES 
user_id=1768698
Originator: YES

I benchmarked using pystone, pybench, and a bunch of my local scientific
applications that have tight computational kernels still in pure Python.  I
tested on a 64bit Linux box, defining the version_tag as either int or
unsigned long with no appreciable difference in performance.  I'm trying to
get parrotbench to run, but it doesn't seem to have been updated for modern
Python versions.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-14 02:21

Message:
Logged In: YES 
user_id=33168
Originator: NO

I tried this test on parrotbench (b0.py in particular) and I'm not sure I
could distinguish an improvement over the noise (best case was about 5%). 
The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc
4.1.2-ish).  At first it seemed a bit slower with the original patch which
uses unsigned ints.  I tried changing to unsigned longs.  It seemed a
little better, though not sure if it was really due to the change.  I think
unsigned longs should be used for 64-bit boxes.

Did you use a benchmark/program that is open source?  I don't know that I
have anything decent to test this with.  Raymond probably does though. 
Also what platform did you test on?

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

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

From noreply at sourceforge.net  Tue May 15 01:47:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 14 May 2007 16:47:42 -0700
Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter
	Unpacking [PEP3113]
Message-ID: <E1HnkGU-0004vJ-T8@sc8-sf-web21.sourceforge.net>

Patches item #1678060, was opened at 2007-03-10 13:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Tony Lownds (tonylownds)
Assigned to: Brett Cannon (bcannon)
Summary: Removal of Tuple Parameter Unpacking [PEP3113]

Initial Comment:
Remove tuple parameter unpacking. The Grammar is now:

typedargslist: ((tfpdef ['=' test] ',')*
                ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef)
                | tfpdef ['=' test] (',' tfpdef ['=' test])* [','])
tfpdef: NAME [':' test]
varargslist: ((vfpdef ['=' test] ',')*
              ('*' [vfpdef] (',' vfpdef ['=' test])*  [',' '**' vfpdef] | '**' vfpdef)
              | vfpdef ['=' test] (',' vfpdef ['=' test])* [','])
vfpdef: NAME

Tuple parameters are removed from Lib/.

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

>Comment By: Brett Cannon (bcannon)
Date: 2007-05-14 16:47

Message:
Logged In: YES 
user_id=357491
Originator: NO

OK, committed on revision 55329 and 55332.  Thanks, Tony!

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

Comment By: Brett Cannon (bcannon)
Date: 2007-05-12 20:09

Message:
Logged In: YES 
user_id=357491
Originator: NO

I have uploaded the current patch I am working off of.  Basically the only
difference is a style choice of not having parentheses in automatic
unpacking.  I also kept a method in the compiler package that was slated to
be removed.

But as of r55280, test_compiler and test_transformer are failing.  I don't
know the compiler package at all, so if you can have a look, Tony, I would
really appreciate it.
File Added: latest.diff

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

Comment By: Brett Cannon (bcannon)
Date: 2007-05-04 22:08

Message:
Logged In: YES 
user_id=357491
Originator: NO

Just so that Tony knows, this patch is next on my TODO list for Python. 
And I will be reviewing your patch instead of doing a blind 2to3
translation.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-23 09:30

Message:
Logged In: YES 
user_id=764593
Originator: NO

Brett,

2to3 is an important tool, but probably won't ever match good hand-work.

(1)  There are several places where he improved the code.

replacing map + an unpacking nested function with a generator:
"""
 def classify_class_attrs(object):
     """Wrap inspect.classify_class_attrs, with fixup for data
descriptors."""
-    def fixup((name, kind, cls, value)):
+    for (name, kind, cls, value) in
inspect.classify_class_attrs(object):
         if inspect.isdatadescriptor(value):
             kind = 'data descriptor'
-        return name, kind, cls, value
-    return map(fixup, inspect.classify_class_attrs(object))
+        yield name, kind, cls, value
"""


Replacing a paren-laden lambda with named function:
"""
-            items = sorted(items, key=lambda (k, v): (str(type(k)), k,
v))
+            def sortkey(item):
+                key, value = item
+                return str(type(key)), key, value
+            items = sorted(items, key=sortkey)
"""

Replacing filter + lambda + unpack with list comprehension:
"""
-        attrs = filter(lambda (name, kind, cls, value):
visiblename(name),
-                       classify_class_attrs(object))
+        attrs = [(name, kind, cls, value)
+                 for name, kind, cls, value in
classify_class_attrs(object)
+                 if visiblename(name)]
"""


(2)  His names are better.

I prefer his (name, result, expected)) over the current (name, (v1,v2),
(e1,e2))), let alone (name, _v1_v2_, _e1_e2_))

Even looking just at code with good existing names, he uses components
instead of _scheme_netloc_url_query_fragment_

So we get (what looks like human-readable source)

-def urlunsplit((scheme, netloc, url, query, fragment)):
+def urlunsplit(components):
+    (scheme, netloc, url, query, fragment) = components

instead of (what looks like the output of a computer translation step)

+def urlunsplit(_scheme_netloc_url_query_fragment_):
+    (scheme, netloc, url, query, fragment) =
_scheme_netloc_url_query_fragment_




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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 16:59

Message:
Logged In: YES 
user_id=357491
Originator: NO

The reason I mention using 2to3 is Collin has done a bunch of work on it
in order to make it also work with lambda.  I believe he also cleaned up
the generated names.

And as for cleaning up the patches, Tony, I can easily edit the diff file
manually, but thanks for the offer.  But if I need you to I will let you
know.

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-22 14:53

Message:
Logged In: YES 
user_id=24100
Originator: YES

Thanks for the comments.

Re: "stuff", if you look at other parts of the code, that is how the
triple is referred to -- fyi on how the name "stuff" came to be :) I was
also at a loss for a better name, and went with the contextual references.

Re: using 2to3 -- Brett, in many cases I actually tried to come up with a
consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like
that. Or it did when I last tried. Anyway, if you end up using 2to3, I
would really appreciate it if you also picked up the inspect.py docstring
change.

Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is
generated code, and that is why "repr" is used. I chose to change the
generation source rather than the generation machinery as I was changing
the source anyway, to account for the changes to parameter syntax. That is
why there are API changes. Given that other API changes were made and those
class constructors are more or less an internal API (created through
compiler.parse),
I believe this is the best way of dealing with the changes.

Brett, If you need me to remove the 2to3 doc toolchain patches, I can do
that.


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

Comment By: Brett Cannon (bcannon)
Date: 2007-03-22 12:57

Message:
Logged In: YES 
user_id=357491
Originator: NO

Chances are I will take Tony's patch for its removal of the feature and
use 2to3 to handle the conversion as much as possible.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:57

Message:
Logged In: YES 
user_id=764593
Originator: NO

On the reprs, is there a reason to call repr instead of using %r?

For example, the Floordiv repr changed to:

"FloorDiv(%s, %s)" % (repr(self.left), repr(self.right))

Why not "FloorDiv(%r, %r)" % (self.left, self.right)

or even, (assuming PEP 3101 with locals,)

"FloorDiv({self.left:r}, {self.right:r})".format()

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

Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-22 05:47

Message:
Logged In: YES 
user_id=764593
Originator: NO

Not sure if any of these are really problems, and it looks like Tony
already looked them over before submitting, but still worth mentioning...

(1)  This does more than take out tuples, though the other changes do also
look like things that ought to change for py3k.

(2)  I was amused by the name "stuff", but I couldn't think of a better
name for that particular grouping.  (suffix, mode, type)

(3)  There are some signature changes, where the unpacking is now done by
the caller, such as 

 class LeftShift(Node):
-    def __init__(self, (left, right), lineno=None):
+    def __init__(self, left, right, lineno=None):

(4)  The pdb change marks could be shortened a bit.  That shouldn't matter
for patching, but I'll post it here since it helped me.

-    def user_exception(self, frame, (exc_type, exc_value,
exc_traceback)):
+    def user_exception(self, frame, exc_info):
         """This function is called if an exception occurs,
         but only if we are to stop at or just below this level."""
+        (exc_type, exc_value, exc_traceback) = exc_info
         frame.f_locals['__exception__'] = exc_type, exc_value      
-        if type(exc_type) == type(''):
-            exc_type_name = exc_type
-        else: exc_type_name = exc_type.__name__
+        exc_type_name = exc_type.__name__
         print(exc_type_name + ':', _saferepr(exc_value),
file=self.stdout)
         self.interaction(frame, exc_traceback)


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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-12 08:07

Message:
Logged In: YES 
user_id=24100
Originator: YES

I found some more code to be removed + a docstring fix in inspect.py.
getfullargspec's docstring lists the 
wrong order for return values. This patch combined the refmanual patch,
previous simplified args patch, 
and 2to3 changes on some doc building tools.

File Added: simplified-args.patch

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

Comment By: Tony Lownds (tonylownds)
Date: 2007-03-11 15:34

Message:
Logged In: YES 
user_id=24100
Originator: YES

File Added: refmanual.patch

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

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

From noreply at sourceforge.net  Tue May 15 21:25:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 12:25:07 -0700
Subject: [Patches] [ python-Patches-1704621 ] interpreter crash when
	multiplying large lists
Message-ID: <E1Ho2dv-00031v-S9@sc8-sf-web22.sourceforge.net>

Patches item #1704621, was opened at 2007-04-20 17:17
Message generated for change (Comment added) made by agthorr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Stutzbach (agthorr)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpreter crash when multiplying large lists

Initial Comment:
Here's a succinct summary of the problem:

>>> x = [0] * 2**20
>>> x *= 2**20
Segmentation fault (core dumped)

>>> x = [0] * 2**20
>>> x * 2**20
[]
>>>

The problem is that list_repeat()'s check for an overflow is flawed, and list_inplace_repeat() doesn't check at all.  Attached is a patch that adds a correct check to both functions.  With the patch, both variations throw a MemoryError exception.  The patch is against Python 2.5, but should also fix 2.5.1/2.6/3.0.

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

>Comment By: Daniel Stutzbach (agthorr)
Date: 2007-05-15 14:25

Message:
Logged In: YES 
user_id=6324
Originator: YES

I just noticed that my last suggestion makes test_tuple fail because
tuple's don't support __imul__.  Here's a revised suggestion:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        if hasattr(x, '__imul__'):
            self.assertRaises(MemoryError, x.__imul__, 2**16)



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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-21 08:29

Message:
Logged In: YES 
user_id=6324
Originator: YES

Yes, I realized the same thing while staring off into space before getting
out of bed this morning. :-)

Here's a simpler version:

x = [0,0,0,0]
self.assertRaises(MemoryError, x.__mul__, sys.maxint/2+1)
self.assertRaises(MemoryError, x.__imul__, sys.maxint/2+1)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 23:14

Message:
Logged In: YES 
user_id=33168
Originator: NO

You could always check the value of sys.maxint.  The test_bigrepeat below
fails quickly on a 64-bit box if you don't have enough memory. :-)  If you
calculated 16 in the __mul__ calls based on sys.maxint, wouldn't that do
what you want?

Perhaps something like:

reasonable_exp = 16
x *= 2 ** reasonable_exp
overflow_exp = int(math.log(sys.maxint, 2)) + 1 - reasonable_exp
self.assertRaises(MemoryError, x.__mul__, 2**overflow_exp)


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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-20 22:55

Message:
Logged In: YES 
user_id=6324
Originator: YES

Sort of.  Below is a test for 32-bit architectures.  Unfortunately, on
architectures where Py_ssize_t is a 64-bit integer, the multiplication
won't overflow and the test really will try to build a list with 2**32
items (which most likely will eventually raise a MemoryError, but it will
take a LONG time!).  This is probably undesirable.  Is there a way to skip
this test for non-32-bit architectures?

One way would be to only perform the test if sys.maxint <= 2**31.

Below is a test that can be added to seq_tests.py:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        self.assertRaises(MemoryError, x.__imul__, 2**16)

While writing the test I found a bug in my patch for the case where the
list is already size 0.  New patch attached.
File Added: list_repeat.patch

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 22:04

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch!

Can you add a test case for both conditions?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 17:41

Message:
Logged In: YES 
user_id=18139
Originator: NO

Yes, I see it.  Patch looks good.  I haven't tested it.

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

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

From noreply at sourceforge.net  Wed May 16 08:34:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 15 May 2007 23:34:17 -0700
Subject: [Patches] [ python-Patches-1704621 ] interpreter crash when
	multiplying large lists
Message-ID: <E1HoD5V-0000L3-BR@sc8-sf-web22.sourceforge.net>

Patches item #1704621, was opened at 2007-04-20 15:17
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Stutzbach (agthorr)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpreter crash when multiplying large lists

Initial Comment:
Here's a succinct summary of the problem:

>>> x = [0] * 2**20
>>> x *= 2**20
Segmentation fault (core dumped)

>>> x = [0] * 2**20
>>> x * 2**20
[]
>>>

The problem is that list_repeat()'s check for an overflow is flawed, and list_inplace_repeat() doesn't check at all.  Attached is a patch that adds a correct check to both functions.  With the patch, both variations throw a MemoryError exception.  The patch is against Python 2.5, but should also fix 2.5.1/2.6/3.0.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-15 23:34

Message:
Logged In: YES 
user_id=33168
Originator: NO

Daniel, could you incorporate the tests and the fix to listobject.c into a
single patch file?  I can then apply that.  Thanks!

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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-05-15 12:25

Message:
Logged In: YES 
user_id=6324
Originator: YES

I just noticed that my last suggestion makes test_tuple fail because
tuple's don't support __imul__.  Here's a revised suggestion:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        if hasattr(x, '__imul__'):
            self.assertRaises(MemoryError, x.__imul__, 2**16)



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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-21 06:29

Message:
Logged In: YES 
user_id=6324
Originator: YES

Yes, I realized the same thing while staring off into space before getting
out of bed this morning. :-)

Here's a simpler version:

x = [0,0,0,0]
self.assertRaises(MemoryError, x.__mul__, sys.maxint/2+1)
self.assertRaises(MemoryError, x.__imul__, sys.maxint/2+1)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 21:14

Message:
Logged In: YES 
user_id=33168
Originator: NO

You could always check the value of sys.maxint.  The test_bigrepeat below
fails quickly on a 64-bit box if you don't have enough memory. :-)  If you
calculated 16 in the __mul__ calls based on sys.maxint, wouldn't that do
what you want?

Perhaps something like:

reasonable_exp = 16
x *= 2 ** reasonable_exp
overflow_exp = int(math.log(sys.maxint, 2)) + 1 - reasonable_exp
self.assertRaises(MemoryError, x.__mul__, 2**overflow_exp)


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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-20 20:55

Message:
Logged In: YES 
user_id=6324
Originator: YES

Sort of.  Below is a test for 32-bit architectures.  Unfortunately, on
architectures where Py_ssize_t is a 64-bit integer, the multiplication
won't overflow and the test really will try to build a list with 2**32
items (which most likely will eventually raise a MemoryError, but it will
take a LONG time!).  This is probably undesirable.  Is there a way to skip
this test for non-32-bit architectures?

One way would be to only perform the test if sys.maxint <= 2**31.

Below is a test that can be added to seq_tests.py:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        self.assertRaises(MemoryError, x.__imul__, 2**16)

While writing the test I found a bug in my patch for the case where the
list is already size 0.  New patch attached.
File Added: list_repeat.patch

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 20:04

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch!

Can you add a test case for both conditions?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 15:41

Message:
Logged In: YES 
user_id=18139
Originator: NO

Yes, I see it.  Patch looks good.  I haven't tested it.

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

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

From noreply at sourceforge.net  Wed May 16 16:47:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 07:47:37 -0700
Subject: [Patches] [ python-Patches-1704621 ] interpreter crash when
	multiplying large lists
Message-ID: <E1HoKmv-0000x7-K1@sc8-sf-web24.sourceforge.net>

Patches item #1704621, was opened at 2007-04-20 17:17
Message generated for change (Comment added) made by agthorr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1704621&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Stutzbach (agthorr)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpreter crash when multiplying large lists

Initial Comment:
Here's a succinct summary of the problem:

>>> x = [0] * 2**20
>>> x *= 2**20
Segmentation fault (core dumped)

>>> x = [0] * 2**20
>>> x * 2**20
[]
>>>

The problem is that list_repeat()'s check for an overflow is flawed, and list_inplace_repeat() doesn't check at all.  Attached is a patch that adds a correct check to both functions.  With the patch, both variations throw a MemoryError exception.  The patch is against Python 2.5, but should also fix 2.5.1/2.6/3.0.

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

>Comment By: Daniel Stutzbach (agthorr)
Date: 2007-05-16 09:47

Message:
Logged In: YES 
user_id=6324
Originator: YES

New patch with test case attached.
File Added: list_repeat.patch

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-16 01:34

Message:
Logged In: YES 
user_id=33168
Originator: NO

Daniel, could you incorporate the tests and the fix to listobject.c into a
single patch file?  I can then apply that.  Thanks!

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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-05-15 14:25

Message:
Logged In: YES 
user_id=6324
Originator: YES

I just noticed that my last suggestion makes test_tuple fail because
tuple's don't support __imul__.  Here's a revised suggestion:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        if hasattr(x, '__imul__'):
            self.assertRaises(MemoryError, x.__imul__, 2**16)



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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-21 08:29

Message:
Logged In: YES 
user_id=6324
Originator: YES

Yes, I realized the same thing while staring off into space before getting
out of bed this morning. :-)

Here's a simpler version:

x = [0,0,0,0]
self.assertRaises(MemoryError, x.__mul__, sys.maxint/2+1)
self.assertRaises(MemoryError, x.__imul__, sys.maxint/2+1)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 23:14

Message:
Logged In: YES 
user_id=33168
Originator: NO

You could always check the value of sys.maxint.  The test_bigrepeat below
fails quickly on a 64-bit box if you don't have enough memory. :-)  If you
calculated 16 in the __mul__ calls based on sys.maxint, wouldn't that do
what you want?

Perhaps something like:

reasonable_exp = 16
x *= 2 ** reasonable_exp
overflow_exp = int(math.log(sys.maxint, 2)) + 1 - reasonable_exp
self.assertRaises(MemoryError, x.__mul__, 2**overflow_exp)


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

Comment By: Daniel Stutzbach (agthorr)
Date: 2007-04-20 22:55

Message:
Logged In: YES 
user_id=6324
Originator: YES

Sort of.  Below is a test for 32-bit architectures.  Unfortunately, on
architectures where Py_ssize_t is a 64-bit integer, the multiplication
won't overflow and the test really will try to build a list with 2**32
items (which most likely will eventually raise a MemoryError, but it will
take a LONG time!).  This is probably undesirable.  Is there a way to skip
this test for non-32-bit architectures?

One way would be to only perform the test if sys.maxint <= 2**31.

Below is a test that can be added to seq_tests.py:

    def test_bigrepeat(self):
        x = self.type2test([0])
        x *= 2**16
        self.assertRaises(MemoryError, x.__mul__, 2**16)
        self.assertRaises(MemoryError, x.__imul__, 2**16)

While writing the test I found a bug in my patch for the case where the
list is already size 0.  New patch attached.
File Added: list_repeat.patch

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-20 22:04

Message:
Logged In: YES 
user_id=33168
Originator: NO

Thanks for the patch!

Can you add a test case for both conditions?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-20 17:41

Message:
Logged In: YES 
user_id=18139
Originator: NO

Yes, I see it.  Patch looks good.  I haven't tested it.

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

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

From noreply at sourceforge.net  Wed May 16 21:13:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 12:13:42 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HoOwQ-0004Dc-2C@sc8-sf-web23.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 19:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 22:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Wed May 16 22:40:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 13:40:22 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HoQII-0006ZD-HF@sc8-sf-web21.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Open
>Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 15:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 14:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May 17 00:23:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 15:23:54 -0700
Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from
	tokanize.c.
Message-ID: <E1HoRuU-0002Jh-Dz@sc8-sf-web21.sourceforge.net>

Patches item #1720390, was opened at 2007-05-16 17:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove backslash escapes from tokanize.c.

Initial Comment:

This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only.

A few strings needed changes in order to compile.  Two in textwrap.py, and one in distutils/util.py.

This does not include changes needed for tests to pass.  I'll include those in a separate patch.


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

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

From noreply at sourceforge.net  Thu May 17 00:31:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 16 May 2007 15:31:03 -0700
Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from
	tokanize.c.
Message-ID: <E1HoS1P-0007kz-U4@sc8-sf-web24.sourceforge.net>

Patches item #1720390, was opened at 2007-05-16 17:23
Message generated for change (Comment added) made by ron_adam
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove backslash escapes from tokanize.c.

Initial Comment:

This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only.

A few strings needed changes in order to compile.  Two in textwrap.py, and one in distutils/util.py.

This does not include changes needed for tests to pass.  I'll include those in a separate patch.


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

>Comment By: Ron Adam (ron_adam)
Date: 2007-05-16 17:31

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Forgot to specify...

This is against the py3k-struni branch, revision 55388.

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

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

From noreply at sourceforge.net  Thu May 17 11:50:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 02:50:16 -0700
Subject: [Patches] [ python-Patches-1720595 ] Allow T_BOOL in PyMemberDef
	definitions
Message-ID: <E1Hocci-0008Eu-Pn@sc8-sf-web23.sourceforge.net>

Patches item #1720595, was opened at 2007-05-17 11:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720595&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Angelo Mottola (lillo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow T_BOOL in PyMemberDef definitions

Initial Comment:
Hello

The attached patch allows to use T_BOOL alongside other common types in the PyMemberDef definitions of your custom types.
The boolean value is assumed to be held in a straight C char variable, and PyMember_SetOne() sets it to 1 or 0 depending on the result of calling PyObject_IsTrue() on the passed value object.


Usage example:


typedef struct ButtonObject
{
	PyObject_HEAD
	char		fToggled;
} ButtonObject;


static PyMemberDef eb_ButtonEventMembers[] = {

	{ "toggled", T_BOOL, offsetof(ButtonObject, fToggled), RO, "True if the button is currently toggled" },
	{ NULL, 0, 0, 0, NULL }
};



The patch has been built against a plain Python 2.5 installation.


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

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

From noreply at sourceforge.net  Thu May 17 17:58:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 08:58:26 -0700
Subject: [Patches] [ python-Patches-1720595 ] Allow T_BOOL in PyMemberDef
	definitions
Message-ID: <E1HoiN0-0006av-6f@sc8-sf-web23.sourceforge.net>

Patches item #1720595, was opened at 2007-05-17 09:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720595&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Angelo Mottola (lillo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow T_BOOL in PyMemberDef definitions

Initial Comment:
Hello

The attached patch allows to use T_BOOL alongside other common types in the PyMemberDef definitions of your custom types.
The boolean value is assumed to be held in a straight C char variable, and PyMember_SetOne() sets it to 1 or 0 depending on the result of calling PyObject_IsTrue() on the passed value object.


Usage example:


typedef struct ButtonObject
{
	PyObject_HEAD
	char		fToggled;
} ButtonObject;


static PyMemberDef eb_ButtonEventMembers[] = {

	{ "toggled", T_BOOL, offsetof(ButtonObject, fToggled), RO, "True if the button is currently toggled" },
	{ NULL, 0, 0, 0, NULL }
};



The patch has been built against a plain Python 2.5 installation.


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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-17 15:58

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'd rather not allow any object to be assigned to the attribute, but only
a bool. T_INT, for example, doesn't automatically call int() on its values
too.

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

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

From noreply at sourceforge.net  Thu May 17 20:13:58 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 11:13:58 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HokUA-0000hC-Ku@sc8-sf-web23.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 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=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

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

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

From noreply at sourceforge.net  Thu May 17 20:17:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 11:17:11 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HokXH-0004C3-Q8@sc8-sf-web21.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

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

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

From noreply at sourceforge.net  Thu May 17 20:25:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 17 May 2007 11:25:20 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HokfA-00056P-5A@sc8-sf-web21.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

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

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

From noreply at sourceforge.net  Fri May 18 15:46:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 06:46:17 -0700
Subject: [Patches] [ python-Patches-1671208 ] Class Decorators
Message-ID: <E1Hp2mf-0006Zp-TY@sc8-sf-web24.sourceforge.net>

Patches item #1671208, was opened at 2007-02-28 15:40
Message generated for change (Comment added) made by jackdied
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671208&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jack Diederich (jackdied)
Assigned to: Jack Diederich (jackdied)
Summary: Class Decorators

Initial Comment:
Patch is against rev 54035 on the pyk3 branch
PEP will be on the 3k list shortly.

Grammar/Grammar is changed from

   funcdef: [decorators] 'def' NAME parameters ['->' test] ':' suite

to

    decorated_thing: decorators (classdef | funcdef)
    funcdef: 'def' NAME parameters ['->' test] ':' suite



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

>Comment By: Jack Diederich (jackdied)
Date: 2007-05-18 09:46

Message:
Logged In: YES 
user_id=591932
Originator: YES

Commited in rev 55430.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-07 15:18

Message:
Logged In: YES 
user_id=6380
Originator: NO

Jack, this patch is out of date w.r.t. the current p3yk branch. Given the
impending acceptance of PEP 3129, could you update it?

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

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

From noreply at sourceforge.net  Fri May 18 23:16:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 18 May 2007 14:16:33 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1Hp9oP-0003f9-BG@sc8-sf-web22.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 15:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-18 17:16

Message:
Logged In: YES 
user_id=984087
Originator: YES

Neal, is there anything else you want me to do for the patch?

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 11:09

Message:
Logged In: YES 
user_id=984087
Originator: YES

josm, please feel free to go to python-dev if you think community input is
required. I personally don't think that it is warranted.

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

Comment By: jos (josm)
Date: 2007-05-13 08:14

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What is intuitive is a matter of taste.
Some people like to count from zero, like many programmers do.

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 07:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, merely changing (fixing) the handling of "depth" parameter is not a
spec change. The patch makes pprint behave in a way that is intuitive from
the meaning of "depth".

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

Comment By: jos (josm)
Date: 2007-05-12 10:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 17:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



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

Comment By: jos (josm)
Date: 2007-05-10 17:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 10:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

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

Comment By: jos (josm)
Date: 2007-05-10 07:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 02:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 10:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 02:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 10:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

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

Comment By: jos (josm)
Date: 2007-05-05 05:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 15:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

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

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

From noreply at sourceforge.net  Sun May 20 04:14:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 19:14:30 -0700
Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from
	tokanize.c.
Message-ID: <E1HpawI-0000o1-JF@sc8-sf-web22.sourceforge.net>

Patches item #1720390, was opened at 2007-05-16 17:23
Message generated for change (Comment added) made by ron_adam
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove backslash escapes from tokanize.c.

Initial Comment:

This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only.

A few strings needed changes in order to compile.  Two in textwrap.py, and one in distutils/util.py.

This does not include changes needed for tests to pass.  I'll include those in a separate patch.


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

>Comment By: Ron Adam (ron_adam)
Date: 2007-05-19 21:14

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Here's a more complete patch which modifies the following files... (in
py3k_struni branch)

M      Python/ast.c
M      Parser/tokenizer.c
M      Lib/test/tokenize_tests.txt
M      Lib/tokenize.py

The test still dosen't pass, but it fails in the same way as it did before
these changes were made.  I'll continue to look into this.  I think it's
more of a problem with the test it self and not a problem with the modules.
 Or it may be a bug in the struni branch that is yet to be fixed.

The following alter one or two raw strings each replacing the outer most
quotes with triple quotes in most cases.

M      Lib/sgmllib.py
M      Lib/markupbase.py
M      Lib/textwrap.py
M      Lib/distutils/util.py
M      Lib/cookielib.py
M      Lib/pydoc.py
M      Lib/doctest.py
M      Lib/xml/etree/ElementTree.py
M      Lib/HTMLParser.py


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

Comment By: Ron Adam (ron_adam)
Date: 2007-05-16 17:31

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Forgot to specify...

This is against the py3k-struni branch, revision 55388.

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

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

From noreply at sourceforge.net  Sun May 20 04:15:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 19 May 2007 19:15:44 -0700
Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from
	tokanize.c.
Message-ID: <E1HpaxU-0000vI-Am@sc8-sf-web22.sourceforge.net>

Patches item #1720390, was opened at 2007-05-16 17:23
Message generated for change (Comment added) made by ron_adam
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove backslash escapes from tokanize.c.

Initial Comment:

This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only.

A few strings needed changes in order to compile.  Two in textwrap.py, and one in distutils/util.py.

This does not include changes needed for tests to pass.  I'll include those in a separate patch.


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

>Comment By: Ron Adam (ron_adam)
Date: 2007-05-19 21:15

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Here's a more complete patch which modifies the following files... (in
py3k_struni branch)

M      Python/ast.c
M      Parser/tokenizer.c
M      Lib/test/tokenize_tests.txt
M      Lib/tokenize.py

The test still dosen't pass, but it fails in the same way as it did before
these changes were made.  I'll continue to look into this.  I think it's
more of a problem with the test it self and not a problem with the modules.
 Or it may be a bug in the struni branch that is yet to be fixed.

The following alter one or two raw strings each replacing the outer most
quotes with triple quotes in most cases.

M      Lib/sgmllib.py
M      Lib/markupbase.py
M      Lib/textwrap.py
M      Lib/distutils/util.py
M      Lib/cookielib.py
M      Lib/pydoc.py
M      Lib/doctest.py
M      Lib/xml/etree/ElementTree.py
M      Lib/HTMLParser.py

File Added: norawescape2.diff

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

Comment By: Ron Adam (ron_adam)
Date: 2007-05-19 21:14

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Here's a more complete patch which modifies the following files... (in
py3k_struni branch)

M      Python/ast.c
M      Parser/tokenizer.c
M      Lib/test/tokenize_tests.txt
M      Lib/tokenize.py

The test still dosen't pass, but it fails in the same way as it did before
these changes were made.  I'll continue to look into this.  I think it's
more of a problem with the test it self and not a problem with the modules.
 Or it may be a bug in the struni branch that is yet to be fixed.

The following alter one or two raw strings each replacing the outer most
quotes with triple quotes in most cases.

M      Lib/sgmllib.py
M      Lib/markupbase.py
M      Lib/textwrap.py
M      Lib/distutils/util.py
M      Lib/cookielib.py
M      Lib/pydoc.py
M      Lib/doctest.py
M      Lib/xml/etree/ElementTree.py
M      Lib/HTMLParser.py


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

Comment By: Ron Adam (ron_adam)
Date: 2007-05-16 17:31

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Forgot to specify...

This is against the py3k-struni branch, revision 55388.

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

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

From noreply at sourceforge.net  Sun May 20 09:59:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 00:59:13 -0700
Subject: [Patches] [ python-Patches-1669481 ] subprocess: Support close_fds
	on Win32
Message-ID: <E1HpgJt-0004vB-E9@sc8-sf-web22.sourceforge.net>

Patches item #1669481, was opened at 2007-02-26 13:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jon Foster (jongfoster)
>Assigned to: Peter ?strand (astrand)
Summary: subprocess: Support close_fds on Win32

Initial Comment:
There is an existing close_fds parameter to the subprocess.Popen() constructor that prevents FDs being copied to the child process on UNIX.  This patch makes that parameter also work on Windows (with a caveat).

Setting this parameter on Windows was explicitly prohibited by the code, because it prevents redirecting stdin/stdout/stderr.  However, the check is too restrictive; it is perfectly reasonable to set this flag if you are not redirecting anything.  That is what this patch does.

The behaviour is unchanged if you are on Windows, set this flag, and simultaneously try to redirect stdin/stdout/stderr: the call will fail with an exception.

This patch is against Python SVN trunk.

Kind regards,

Jon Foster


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-20 00:59

Message:
Logged In: YES 
user_id=33168
Originator: NO

Peter, could you take a look at this patch?

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

Comment By: Jason Orendorff (jorend)
Date: 2007-04-23 06:53

Message:
Logged In: YES 
user_id=18139
Originator: NO

Patch looks good.  +1 (but I haven't tested it either).


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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-08 12:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

The patch looks good; unfortunately I don't have a Windows to test it,
otherwise I'd apply it.

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

Comment By: Jon Foster (jongfoster)
Date: 2007-03-07 15:11

Message:
Logged In: YES 
user_id=199289
Originator: YES

I've been reading the general discussion on python-dev about patches
needing documentation and tests.  So here's an updated patch that includes
docs and tests.
File Added: subprocess_win32_close_handles_2.patch

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

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

From noreply at sourceforge.net  Sun May 20 17:30:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 08:30:54 -0700
Subject: [Patches] [ python-Patches-1686487 ] Allow any mapping after ** in
	calls
Message-ID: <E1HpnN0-0005Yw-KJ@sc8-sf-web24.sourceforge.net>

Patches item #1686487, was opened at 2007-03-22 23:27
Message generated for change (Comment added) made by belopolsky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow any mapping after ** in calls

Initial Comment:
Python allows arbitrary sequences after * in calls, but an expression following ** must be a (subclass of) dict.  The attached patch makes Python accept arbitrary mappings after **. 

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

>Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-05-20 11:30

Message:
Logged In: YES 
user_id=835142
Originator: YES

What else needs to be done for the patch to go in?  Guido OKed the feature
and zseil gave a favorable code review.  Is there any reason not to apply
it?

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-24 09:19

Message:
Logged In: YES 
user_id=835142
Originator: YES

zseil: It would be nice if it contained the information about kwdict's
type.

I agree, the new patch adds type information to both * and ** error
messages.
File Added: star-star-mapping-msg.patch

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-24 06:32

Message:
Logged In: YES 
user_id=1326842
Originator: NO

The patch looks good to me.  The only thing that could
be improved is the error message.  It would be nice if
it contained the information about kwdict's type.


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 15:53

Message:
Logged In: YES 
user_id=835142
Originator: YES

File Added: star-star-mapping.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 15:38

Message:
Logged In: YES 
user_id=835142
Originator: YES

The proposed patch handles ** arguments similar to the way * arguments are
treated.  If the expression following ** evaluates to an object that is not
a dictionary, the new code attempts to update a new dictionary with that
object. This procedure is closely similar to what PySequence_Tuple does
with * arguments. (Python API does not provide PyMapping_Dict.) If new
dictionary is succesfully created and updated, it replaces the original **
argument. If that attempt fails because kwdict is not a mapping (does not
have a 'keys' attribute, a type error is raised explaining that a mapping
is expected.  All other errors, e.g. MemoryError are percolated up.

(I am am removing the previous versions of the patch.)
File Added: star-star-mapping.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 14:34

Message:
Logged In: YES 
user_id=835142
Originator: YES

Georg,

Thanks for reposting my proposal. Since BDFL is +1 on the idea, I feel
motivated to polish the patch.  In your early comment you noted that kwdict
== NULL check may be superficial.  I agree.  It does not look like it is
possible that ext_do_call is called with CALL_FLAG_KW set and a null
pointer at the top of the stack.  It looks like this may only happen if the
stack is corrupted by a misbehaving c extension.  In this case, however,
throwing a type error is too gentle. PyErr_BadInternalCall() seems to be
more appropriate if anything at all.

I propose to eliminate the null check for kwdict alltogether. This would
be consistent with the way stararg is handled later in this function.  I am
going to run the testsuit without the null check and will post a revised
patch shortly.




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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 12:02

Message:
Logged In: YES 
user_id=835142
Originator: YES

I have asked on python-dev almost a month ago, but did not get any
response:

http://mail.python.org/pipermail/python-dev/2007-March/072321.html

I have recently posted another message that got no response as well:

http://mail.python.org/pipermail/python-dev/2007-April/072653.html

Is it possible that my messages are not being delivered to the list?


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-03-23 15:44

Message:
Logged In: YES 
user_id=835142
Originator: YES

I've fixed the flaws in star-star-mapping-1.patch .  I will ask on
python-dev about the feature.  If the proposal is accepted, I will probably
refactor the code to avoid using the second goto label.
File Added: star-star-mapping-1.patch

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 14:45

Message:
Logged In: YES 
user_id=849994
Originator: NO

Two flaws:
- what if kwdict is NULL? Shouldn't happen, but the old version raises an
error in this case.
- if PyDict_Update fails, tmpdict is leaked.

Please ask on python-dev whether to include this feature.

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

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

From noreply at sourceforge.net  Sun May 20 19:11:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 20 May 2007 10:11:49 -0700
Subject: [Patches] [ python-Patches-1722225 ] Build on QNX
Message-ID: <E1Hpowf-0001zH-5D@sc8-sf-web21.sourceforge.net>

Patches item #1722225, was opened at 2007-05-20 10:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build on QNX

Initial Comment:
The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

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

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

From noreply at sourceforge.net  Mon May 21 20:22:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 11:22:20 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HqCWS-0001D0-J5@sc8-sf-web22.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

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

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

From noreply at sourceforge.net  Mon May 21 20:24:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 11:24:26 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HqCYU-0001Qh-CY@sc8-sf-web22.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

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

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

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

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

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

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

From noreply at sourceforge.net  Mon May 21 22:34:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 13:34:31 -0700
Subject: [Patches] [ python-Patches-1686487 ] Allow any mapping after ** in
	calls
Message-ID: <E1HqEaN-0002gv-H9@sc8-sf-web24.sourceforge.net>

Patches item #1686487, was opened at 2007-03-23 03:27
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow any mapping after ** in calls

Initial Comment:
Python allows arbitrary sequences after * in calls, but an expression following ** must be a (subclass of) dict.  The attached patch makes Python accept arbitrary mappings after **. 

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

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-21 20:34

Message:
Logged In: YES 
user_id=849994
Originator: NO

I think it just needs someone to commit it. ;) See revision 55495.

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-05-20 15:30

Message:
Logged In: YES 
user_id=835142
Originator: YES

What else needs to be done for the patch to go in?  Guido OKed the feature
and zseil gave a favorable code review.  Is there any reason not to apply
it?

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-24 13:19

Message:
Logged In: YES 
user_id=835142
Originator: YES

zseil: It would be nice if it contained the information about kwdict's
type.

I agree, the new patch adds type information to both * and ** error
messages.
File Added: star-star-mapping-msg.patch

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

Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-24 10:32

Message:
Logged In: YES 
user_id=1326842
Originator: NO

The patch looks good to me.  The only thing that could
be improved is the error message.  It would be nice if
it contained the information about kwdict's type.


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 19:53

Message:
Logged In: YES 
user_id=835142
Originator: YES

File Added: star-star-mapping.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 19:38

Message:
Logged In: YES 
user_id=835142
Originator: YES

The proposed patch handles ** arguments similar to the way * arguments are
treated.  If the expression following ** evaluates to an object that is not
a dictionary, the new code attempts to update a new dictionary with that
object. This procedure is closely similar to what PySequence_Tuple does
with * arguments. (Python API does not provide PyMapping_Dict.) If new
dictionary is succesfully created and updated, it replaces the original **
argument. If that attempt fails because kwdict is not a mapping (does not
have a 'keys' attribute, a type error is raised explaining that a mapping
is expected.  All other errors, e.g. MemoryError are percolated up.

(I am am removing the previous versions of the patch.)
File Added: star-star-mapping.patch

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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 18:34

Message:
Logged In: YES 
user_id=835142
Originator: YES

Georg,

Thanks for reposting my proposal. Since BDFL is +1 on the idea, I feel
motivated to polish the patch.  In your early comment you noted that kwdict
== NULL check may be superficial.  I agree.  It does not look like it is
possible that ext_do_call is called with CALL_FLAG_KW set and a null
pointer at the top of the stack.  It looks like this may only happen if the
stack is corrupted by a misbehaving c extension.  In this case, however,
throwing a type error is too gentle. PyErr_BadInternalCall() seems to be
more appropriate if anything at all.

I propose to eliminate the null check for kwdict alltogether. This would
be consistent with the way stararg is handled later in this function.  I am
going to run the testsuit without the null check and will post a revised
patch shortly.




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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-18 16:02

Message:
Logged In: YES 
user_id=835142
Originator: YES

I have asked on python-dev almost a month ago, but did not get any
response:

http://mail.python.org/pipermail/python-dev/2007-March/072321.html

I have recently posted another message that got no response as well:

http://mail.python.org/pipermail/python-dev/2007-April/072653.html

Is it possible that my messages are not being delivered to the list?


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

Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-03-23 19:44

Message:
Logged In: YES 
user_id=835142
Originator: YES

I've fixed the flaws in star-star-mapping-1.patch .  I will ask on
python-dev about the feature.  If the proposal is accepted, I will probably
refactor the code to avoid using the second goto label.
File Added: star-star-mapping-1.patch

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 18:45

Message:
Logged In: YES 
user_id=849994
Originator: NO

Two flaws:
- what if kwdict is NULL? Shouldn't happen, but the old version raises an
error in this case.
- if PyDict_Update fails, tmpdict is leaked.

Please ask on python-dev whether to include this feature.

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

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

From noreply at sourceforge.net  Mon May 21 23:00:33 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 21 May 2007 14:00:33 -0700
Subject: [Patches] [ python-Patches-1723038 ] Curses Menu
Message-ID: <E1HqEzZ-00046q-6J@sc8-sf-web22.sourceforge.net>

Patches item #1723038, was opened at 2007-05-21 23:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1723038&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabian Frederick (ffrederick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Curses Menu

Initial Comment:
Here's both menu & items wrappers for ncurses based on curses_panel.
Feedback appreciated before I try to add support for other functions.

Regards,
Fabian

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

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

From noreply at sourceforge.net  Wed May 23 07:29:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 22 May 2007 22:29:43 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1HqjPr-0004Db-Mk@sc8-sf-web23.sourceforge.net>

Patches item #1718153, was opened at 2007-05-13 07:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718153&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-22 22:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Wed May 23 23:55:32 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 23 May 2007 14:55:32 -0700
Subject: [Patches] [ python-Patches-1718153 ] PEP 3123 implementation
Message-ID: <E1Hqyns-0006BH-HV@sc8-sf-web24.sourceforge.net>

Patches item #1718153, was opened at 2007-05-13 16:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718153&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 3123 implementation

Initial Comment:
This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

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

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

I don't think API compatibility between 2.5 and 3.0 should be a
requirement - I expect that there will be much more breakage, making such
compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including
HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

I like this patch would like it to be applied to 2.6.  However, I'm
concerned about extension modules maintaining compatibility for 2.5 and
3.0.  What would that look like (ie, an extension module that can compile
with both versions)?  How would the modules need to be changed to support
both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward
to define the macros in 2.x and things should work fine.  But I'm not sure
about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to
see if there were any warnings?

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

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

From noreply at sourceforge.net  Thu May 24 14:36:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 05:36:03 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrCXz-0004UN-8I@sc8-sf-web21.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Pending
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 20:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 19:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 22:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May 24 14:49:52 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 05:49:52 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrClM-0004fk-4f@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Open
>Resolution: None
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 07:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 07:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 15:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 14:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

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

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

From noreply at sourceforge.net  Thu May 24 17:53:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 08:53:44 -0700
Subject: [Patches] [ python-Patches-1724999 ] dict size changes during iter
Message-ID: <E1HrFdI-0002O2-PT@sc8-sf-web21.sourceforge.net>

Patches item #1724999, was opened at 2007-05-24 19:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1724999&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. L?wis (loewis)
Summary: dict size changes during iter

Initial Comment:
In p3yk branch and Ubuntu 2.6.20-15

In::

  from Tkinter import *


  root = Tk()
  toplevel = Toplevel()
  def destroy():
      toplevel.destroy()
  button = Button(toplevel, text='Press Me',
                  command=destroy)
  button.pack()
  toplevel.focus_set()

  root.mainloop()

When the button is pressed I get::

  Exception in Tkinter callback
  Traceback (most recent call last):
    File "/usr/local/lib/python3.0/lib-tk/Tkinter.py", line 1403, in __call__
      return self.func(*args)
    File "mod.py", line 7, in destroy
      toplevel.destroy()
    File "/usr/local/lib/python3.0/lib-tk/Tkinter.py", line 1935, in destroy
      for c in self.children.values(): c.destroy()
  RuntimeError: dictionary changed size during iteration

The attached patch solves this.

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

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

From noreply at sourceforge.net  Thu May 24 19:55:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 10:55:42 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrHXK-0000WO-6V@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Pending
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

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

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 17:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 12:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 20:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

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

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 19:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 22:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

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

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

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

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

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

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


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

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

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

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Thu May 24 20:10:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 11:10:02 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrHlC-0007Vg-Pb@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

----------------------------------------------------------------------

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 13:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all system loggers support sockets. In my real-world situation, this
is Metalog (on Gentoo). Thread safety is a concern, but single-thread
support is better than none for now.

How would I go about doing a conditional import for Windows compatibility?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 07:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 07:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 15:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 14:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Fri May 25 03:45:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 18:45:11 -0700
Subject: [Patches] [ python-Patches-1725295 ] Line ending bug
	SimpleXMLRPCServer
Message-ID: <E1HrOrf-0002sH-Nr@sc8-sf-web24.sourceforge.net>

Patches item #1725295, was opened at 2007-05-24 21:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725295&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bgrubbs (bgrubbs)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line ending bug SimpleXMLRPCServer

Initial Comment:
Apache on windows generates an incorrect Content-length
because \n is converted to \r\n if stdout is a terminal
unless it is set to binary mode

This patch fixes the issue: Apache on win32 using CGIXMLRPCRequestHandler returns incorrect Content-length

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725295&group_id=5470

From noreply at sourceforge.net  Fri May 25 05:52:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 20:52:11 -0700
Subject: [Patches] [ python-Patches-1254718 ] GCC detection for
	runtime_library_dirs when ccache is used
Message-ID: <E1HrQqZ-0005uD-5C@sc8-sf-web22.sourceforge.net>

Patches item #1254718, was opened at 2005-08-09 13:53
Message generated for change (Comment added) made by sanxiyn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1254718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Seo Sanghyeon (sanxiyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: GCC detection for runtime_library_dirs when ccache is used

Initial Comment:
Recently I discovered ccache and am very happily using it.

However, some Python extensions (python-ldap, to be
precise) didn't link correctly, ignoring
runtime_library_dirs, only if I used ccache.
(CC='ccache gcc' python setup.py...)

Attached patch fixes this by treating any compiler with
string gcc or g++ in it as GCC, not only those start
with gcc or g++. This feels like hack over hack, but oh
well.

----------------------------------------------------------------------

>Comment By: Seo Sanghyeon (sanxiyn)
Date: 2007-05-25 12:52

Message:
Logged In: YES 
user_id=837148
Originator: YES

This is a part of Gentoo Python patchset.
http://gentoo.osuosl.org/distfiles/python-gentoo-patches-2.5.1.tar.bz2

----------------------------------------------------------------------

Comment By: Rick (rickharris)
Date: 2006-07-01 10:41

Message:
Logged In: YES 
user_id=1269204

Patch is good, bug still exists and not limited to just 
ccache users.

On many systems using gcc, 'CC' does not == "gcc".

For example, on this 
system /usr/lib/python2.4/config/Makefile reads
'CC=i686-pc-linux-gnu-gcc -pthread'

Therefore distutils will never link the RPATH/RUNPATH into 
the .so correctly.
If any of the libraries linked against are in directories 
that are not in the system's LDPATH, then the application 
will fail when it cannot find the linked library.


----------------------------------------------------------------------

Comment By: Seo Sanghyeon (sanxiyn)
Date: 2005-08-09 16:08

Message:
Logged In: YES 
user_id=837148

Hye-Shik Chang pointed out that Intel C Compiler(icc) needs
-Wl,-R as well, not -R. Perhaps this should check for icc too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1254718&group_id=5470

From noreply at sourceforge.net  Fri May 25 07:29:01 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 24 May 2007 22:29:01 -0700
Subject: [Patches] [ python-Patches-1722225 ] Build on QNX
Message-ID: <E1HrSMH-0007IJ-5Q@sc8-sf-web24.sourceforge.net>

Patches item #1722225, was opened at 2007-05-20 10:11
Message generated for change (Comment added) made by kraai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Build
>Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build on QNX

Initial Comment:
The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

----------------------------------------------------------------------

>Comment By: Matt Kraai (kraai)
Date: 2007-05-24 22:29

Message:
Logged In: YES 
user_id=1471342
Originator: YES

Here's an updated patch.  It's changed relative to the first one in that
it makes the workaround for the incompatibility between [n]curses.h and
stdlib.h be handled similar to how it's handled for other platforms, it
prevents _XOPEN_SOURCE from being defined to allow the socket module to
build, and it merges the QNX case for setting LDSHARED.

I tried to include the changes to configure and pyconfig.h.in, but that
made it too big.  If they need to be submitted, please let me how to do so.
File Added: patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

From noreply at sourceforge.net  Fri May 25 09:44:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 00:44:12 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrUT6-0003FF-7P@sc8-sf-web22.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Pending
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 07:44

Message:
Logged In: YES 
user_id=308438
Originator: NO

Unfortunately, while thread safety remains a concern, I won't be able to
put in a patch - I don't have time to handle any additional support
requests or bug reports. Since you have a patch which works for you, I
suggest you stick with it. Any further updates to the module should be
fairly easy for you to merge with e.g. Meld.

A conditional import for Windows compatibility would be something like
this:

try:
    import syslog # Will fail where unavailable, e.g. Windows
except ImportError:
    syslog = None

and then, later, in the relevant code:

    if syslog is None:
        # Code avoiding use of syslog module
    else:
        # Code using syslog module



----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 18:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all system loggers support sockets. In my real-world situation, this
is Metalog (on Gentoo). Thread safety is a concern, but single-thread
support is better than none for now.

How would I go about doing a conditional import for Windows compatibility?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 17:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 12:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 20:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 19:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 22:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Fri May 25 12:35:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 03:35:08 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrX8W-0004K5-Ux@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

----------------------------------------------------------------------

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-25 05:35

Message:
Logged In: YES 
user_id=25634
Originator: YES

What logic allows you to reject/postpone this bugfix, but not
reject/postpone other patchless bug reports to fix more specifics? Better
to have this work as non-thread-safe than not at all, even if the eventual
ideal is thread-safe. I find it hard to believe that thread-safety is
consistently present throughout the rest of the Python library.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 02:44

Message:
Logged In: YES 
user_id=308438
Originator: NO

Unfortunately, while thread safety remains a concern, I won't be able to
put in a patch - I don't have time to handle any additional support
requests or bug reports. Since you have a patch which works for you, I
suggest you stick with it. Any further updates to the module should be
fairly easy for you to merge with e.g. Meld.

A conditional import for Windows compatibility would be something like
this:

try:
    import syslog # Will fail where unavailable, e.g. Windows
except ImportError:
    syslog = None

and then, later, in the relevant code:

    if syslog is None:
        # Code avoiding use of syslog module
    else:
        # Code using syslog module



----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 13:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all system loggers support sockets. In my real-world situation, this
is Metalog (on Gentoo). Thread safety is a concern, but single-thread
support is better than none for now.

How would I go about doing a conditional import for Windows compatibility?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 07:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 07:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 15:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 14:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Fri May 25 15:09:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 06:09:57 -0700
Subject: [Patches] [ python-Patches-1725576 ] IDLE - cursor color
	configuration bug
Message-ID: <E1HrZYL-0004Ft-FI@sc8-sf-web24.sourceforge.net>

Patches item #1725576, was opened at 2007-05-25 16:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725576&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE - cursor color configuration bug

Initial Comment:
Currently, IDLE must be restarted in order for a change to the cursor color to take effect.

This patch adds code to configDialog.py to update the text widgets in all windows with the new cursor color.

This closes SourceForge feature request 1705362.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725576&group_id=5470

From noreply at sourceforge.net  Fri May 25 15:45:17 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 06:45:17 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1Hra6X-0008D2-SL@sc8-sf-web24.sourceforge.net>

Patches item #1711603, was opened at 2007-05-03 00:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Pending
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 13:45

Message:
Logged In: YES 
user_id=308438
Originator: NO

It's not a bugfix - it's an enhancement, which no one else has asked for.
Given that there's a possible thread safety issue, I see no strong reason
to commit a patch to call syslog. After all, you have a patch which works
for you; and there is no strong demand in the community for a patch to use
syslog. Keep using your patch, where's the problem with that?

I look at bug reports and patches and fix/apply after assessing whether or
not the change is an improvement. I don't accept all patches or bug reports
as valid - but I don't reject things out of hand, either. This particular
patch might make things worse if thread safefy issues aren't thought
through properly - then it would be me, not you, who would have to take on
any additional support burden. While I can't speak for the Python library
as a whole, I have certainly taken a fair amount of trouble to make the
logging package thread-safe.

Take a look at the patches list for Python - there are quite a lot of
patches which aren't accepted and haven't been accepted for a long time
because that's the committer's judgement. Some may get accepted in the
future, others will not.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-25 10:35

Message:
Logged In: YES 
user_id=25634
Originator: YES

What logic allows you to reject/postpone this bugfix, but not
reject/postpone other patchless bug reports to fix more specifics? Better
to have this work as non-thread-safe than not at all, even if the eventual
ideal is thread-safe. I find it hard to believe that thread-safety is
consistently present throughout the rest of the Python library.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 07:44

Message:
Logged In: YES 
user_id=308438
Originator: NO

Unfortunately, while thread safety remains a concern, I won't be able to
put in a patch - I don't have time to handle any additional support
requests or bug reports. Since you have a patch which works for you, I
suggest you stick with it. Any further updates to the module should be
fairly easy for you to merge with e.g. Meld.

A conditional import for Windows compatibility would be something like
this:

try:
    import syslog # Will fail where unavailable, e.g. Windows
except ImportError:
    syslog = None

and then, later, in the relevant code:

    if syslog is None:
        # Code avoiding use of syslog module
    else:
        # Code using syslog module



----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 18:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all system loggers support sockets. In my real-world situation, this
is Metalog (on Gentoo). Thread safety is a concern, but single-thread
support is better than none for now.

How would I go about doing a conditional import for Windows compatibility?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 17:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 12:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 20:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 19:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 22:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 21:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 15:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 12:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 16:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-06 09:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 17:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 13:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-03 00:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Fri May 25 17:10:15 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 08:10:15 -0700
Subject: [Patches] [ python-Patches-1711603 ] syslog syscall support for
	SysLogLogger
Message-ID: <E1HrbQl-0002B8-EZ@sc8-sf-web21.sourceforge.net>

Patches item #1711603, was opened at 2007-05-02 19:12
Message generated for change (Comment added) made by luke-jr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
>Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Luke-Jr (luke-jr)
Assigned to: Nobody/Anonymous (nobody)
Summary: syslog syscall support for SysLogLogger

Initial Comment:
This allows SysLogLogger to be used via the normal syslog syscall.

----------------------------------------------------------------------

>Comment By: Luke-Jr (luke-jr)
Date: 2007-05-25 10:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

This would be the equivalent to having a EmailLogger that supports XMPP
and IMAP, but not SMTP. I don't see how you can argue it as not being a
bug.

I have a patch that works, yes, but to make use of it, I need to patch
Python every time I upgrade, as would all my users. Seeing as we are all
users of the Python language, not developers of it, manual patching should
*not* be necessary. The SyslogLogger could easily contain a documented note
that syscall support may not be thread-safe. Note that in practice, I
haven't had any problems-- the application I am writing is highly threaded.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 08:45

Message:
Logged In: YES 
user_id=308438
Originator: NO

It's not a bugfix - it's an enhancement, which no one else has asked for.
Given that there's a possible thread safety issue, I see no strong reason
to commit a patch to call syslog. After all, you have a patch which works
for you; and there is no strong demand in the community for a patch to use
syslog. Keep using your patch, where's the problem with that?

I look at bug reports and patches and fix/apply after assessing whether or
not the change is an improvement. I don't accept all patches or bug reports
as valid - but I don't reject things out of hand, either. This particular
patch might make things worse if thread safefy issues aren't thought
through properly - then it would be me, not you, who would have to take on
any additional support burden. While I can't speak for the Python library
as a whole, I have certainly taken a fair amount of trouble to make the
logging package thread-safe.

Take a look at the patches list for Python - there are quite a lot of
patches which aren't accepted and haven't been accepted for a long time
because that's the committer's judgement. Some may get accepted in the
future, others will not.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-25 05:35

Message:
Logged In: YES 
user_id=25634
Originator: YES

What logic allows you to reject/postpone this bugfix, but not
reject/postpone other patchless bug reports to fix more specifics? Better
to have this work as non-thread-safe than not at all, even if the eventual
ideal is thread-safe. I find it hard to believe that thread-safety is
consistently present throughout the rest of the Python library.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-25 02:44

Message:
Logged In: YES 
user_id=308438
Originator: NO

Unfortunately, while thread safety remains a concern, I won't be able to
put in a patch - I don't have time to handle any additional support
requests or bug reports. Since you have a patch which works for you, I
suggest you stick with it. Any further updates to the module should be
fairly easy for you to merge with e.g. Meld.

A conditional import for Windows compatibility would be something like
this:

try:
    import syslog # Will fail where unavailable, e.g. Windows
except ImportError:
    syslog = None

and then, later, in the relevant code:

    if syslog is None:
        # Code avoiding use of syslog module
    else:
        # Code using syslog module



----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 13:10

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all system loggers support sockets. In my real-world situation, this
is Metalog (on Gentoo). Thread safety is a concern, but single-thread
support is better than none for now.

How would I go about doing a conditional import for Windows compatibility?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 12:55

Message:
Logged In: YES 
user_id=308438
Originator: NO

I didn't close the patch, I just marked it as "Pending" - not the same
thing as closing, but giving an opportunity for an improved patch to be
uploaded, and putting the ball in your court. And opinions differ about the
"standard method" - in fact the UDP/domain socket SysLogHandler
implementation was contributed by someone who was using it in a real-world
scenario. The syslog call method doesn't appear to provide the ability to
log to remote daemons - so the UDP/domain socket route would appear to
cover all bases. Are you saying that you are not able to use UDP or Unix
sockets in your environment? Can you please give more details about this
environment - operating system, version etc.? What about my comment about
thread safety of syslog, which you have not addressed?

Marking this item's status as Pending (i.e. ball in your court) and
resolution as Rejected (indicating that the patch cannot be accepted as is
due to breakage on Windows).

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-24 07:49

Message:
Logged In: YES 
user_id=25634
Originator: YES

The purpose of the SysLogHandler is to log to the system logger. The
standard method for doing this is via the syscall. UDP and UNIX sockets are
*additional* methods that are not necessarily supported by all system
logging daemons.

If the patch needs work, that's no reason to close it altogether.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-24 07:36

Message:
Logged In: YES 
user_id=308438
Originator: NO

The whole purpose of the module is not to log to syslog - it logs to a
variety of destinations. If you meant the SysLogHandler class - why exactly
do you need the syslogging to be done via a syscall? You have two options
already - log using a hostname/port for local or remote daemons, or use
e.g. address="/dev/log" to use a Unix domain socket for access to the local
syslog daemon. So I'm not sure how the purpose is defeated.

The patch as it stands will not import cleanly in Windows (since there is
no "syslog" module there), so it cannot be accepted as it stands.
Ordinarily I would make any small amendments myself, but at the moment I
don't have the time.

You should also be aware that the syslog module may not be thread-safe on
all platforms - for instance, see the first Google hit I got for the query
"syslog openlog":

http://www.unet.univie.ac.at/aix/libs/basetrf2/syslog.htm

Now logging does provide an I/O lock, but that's only around the emit()
call. Your syslog calls have a broader scope (handler open/close) and I'm
not sure whether thread-safety could be guaranteed in all cases.

If you want to work up a patch which works across platforms and can allay
my worries about multi-threading, I'll certainly look at it again.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-16 15:40

Message:
Logged In: YES 
user_id=25634
Originator: YES

There is no syslog on Windows period. I guess you'd better remove chmod
support from Python as well-- Windows doesn't use UNIX permissions! The
whole purpose of this module is to log to syslog; the standard way for this
is via a syscall. Not supporting the syscall kindof defeats the purpose.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2007-05-16 14:13

Message:
Logged In: YES 
user_id=308438
Originator: NO

The use of syslog is system-specific - there is no syslog syscall on
Windows.

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 17:16

Message:
Logged In: YES 
user_id=25634
Originator: YES

Yes, that might be a sane thing to add :)
That exact problem bit me a few days ago, actually (I'm using this code
already).

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 16:52

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Now I understand. Thank you for your patience :)

BTW, wouldn't it be nice to do os.path.basename() on ident?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-10 10:09

Message:
Logged In: YES 
user_id=25634
Originator: YES

No, 'syslog' wouldn't work because the running program's name is not
'syslog'. It should be the same name as appears in the process list, which
is argv[0]

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 07:31

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Sorry, I quoted wrong PEP... PEP 7 is for C code, not Python's one.
PEP 8 is right guide.

I'm still wondering whether using sys.argv[0] for default value is valid
or not.
How about changing this as ident = 'syslog'?
doesn't that work?


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.04.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-06 11:05

Message:
Logged In: YES 
user_id=25634
Originator: YES

The 'ident' value is normally the name of the program, which should be
argv[0]. I prefer and normally use single-tab indents. However, when
patching code, I adjust to the existing standard within the source. In this
case, my handlers.py was already indented with spaces so I conformed to
that. I glanced at svn before posting this, and it doesn't appear to be
much different for this file.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-06 04:58

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Thank you for your reply.

A few more comments and requests.

+    def __init__(self, address=('localhost', SYSLOG_UDP_PORT),
facility=LOG_USER, ident=sys.argv[0]):

Why sys.argv[0]? Assuming command line arguments doesn't look reasonable
to me.

+        self.unixsocket = 0
+	self.syscall = 0

Please use single-tab indents. (PEP7)


Can I have the patch patch against the svn repository?
(against trunk should be preferable)
I had some problem applying your patch.


----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-05 12:28

Message:
Logged In: YES 
user_id=25634
Originator: YES

Not all syslog daemons accept socket connections. For example, metalog.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 08:25

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What advantage does OS's syslog have over the logging module's one?
I've never been familiar with syslog,
So could you please tell me the difference?

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:22

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.03.patch

----------------------------------------------------------------------

Comment By: Luke-Jr (luke-jr)
Date: 2007-05-02 19:14

Message:
Logged In: YES 
user_id=25634
Originator: YES

File Added: SysLogHandler-syslog-0.02.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1711603&group_id=5470

From noreply at sourceforge.net  Fri May 25 18:44:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 09:44:44 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1HrcuC-00010z-RN@sc8-sf-web22.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 19:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Fri May 25 21:16:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 12:16:27 -0700
Subject: [Patches] [ python-Patches-1722225 ] Build on QNX
Message-ID: <E1HrfH1-0004TF-3j@sc8-sf-web23.sourceforge.net>

Patches item #1722225, was opened at 2007-05-20 17:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
>Assigned to: Martin v. L?wis (loewis)
Summary: Build on QNX

Initial Comment:
The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-25 19:16

Message:
Logged In: YES 
user_id=849994
Originator: NO

Martin, will you take a look?

----------------------------------------------------------------------

Comment By: Matt Kraai (kraai)
Date: 2007-05-25 05:29

Message:
Logged In: YES 
user_id=1471342
Originator: YES

Here's an updated patch.  It's changed relative to the first one in that
it makes the workaround for the incompatibility between [n]curses.h and
stdlib.h be handled similar to how it's handled for other platforms, it
prevents _XOPEN_SOURCE from being defined to allow the socket module to
build, and it merges the QNX case for setting LDSHARED.

I tried to include the changes to configure and pyconfig.h.in, but that
made it too big.  If they need to be submitted, please let me how to do so.
File Added: patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

From noreply at sourceforge.net  Sat May 26 00:15:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 15:15:23 -0700
Subject: [Patches] [ python-Patches-1708353 ] Make isinstance/issubclass
	overloadable for PEP 3119
Message-ID: <E1Hri4B-0004G2-RB@sc8-sf-web22.sourceforge.net>

Patches item #1708353, was opened at 2007-04-26 16:16
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1708353&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Make isinstance/issubclass overloadable for PEP 3119

Initial Comment:
I came up with a fairly simple way to overload isinstance() and issubclass().  The class that is the second argument can define a (class) method named __instancecheck__ or __subclasscheck__ which, if present, will be called *instead* of the normal approach.

The names are different to remind users that the calling convention is the opposite -- isinstance(x, C) maps to C.__instancecheck__(x).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-25 18:15

Message:
Logged In: YES 
user_id=6380
Originator: YES

Checked in. The recursion bug is warded off by a standard recursion check
-- you'll now get an inexplicable RuntimeError exception instead of an
inexplicable SegFault. :-)

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-12 15:27

Message:
Logged In: YES 
user_id=849994
Originator: NO

Probably a warning would be good for the non-classmethod case.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 17:40

Message:
Logged In: YES 
user_id=6380
Originator: YES

FWIW, this can run into unchecked infinite recursion easily:

class C:
    # There's no @classmethod decorator here as there should have been
    def __instancecheck__(self, arg):
        return False

isinstance(42, C)

The reason is that on line 372 in classobject.c there's a call to
PyObject_IsInstance(self, klass).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-11 10:16

Message:
Logged In: YES 
user_id=6380
Originator: YES

Version 3 compiles with older C89 compilers like gcc 2.96.
File Added: typechecks.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 17:27

Message:
Logged In: YES 
user_id=6380
Originator: YES

I'll add a description and motivation for this to PEP 3119.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-26 16:34

Message:
Logged In: YES 
user_id=6380
Originator: YES

Oops, forget the first attempt; isinstance(Integer(), Integer) would be
False!  Now it's True, and more tests are added.
File Added: typechecks.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1708353&group_id=5470

From noreply at sourceforge.net  Sat May 26 04:12:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 19:12:57 -0700
Subject: [Patches] [ python-Patches-1722225 ] Build on QNX
Message-ID: <E1Hrlm5-0001GA-Lc@sc8-sf-web21.sourceforge.net>

Patches item #1722225, was opened at 2007-05-20 10:11
Message generated for change (Comment added) made by kraai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
Assigned to: Martin v. L?wis (loewis)
Summary: Build on QNX

Initial Comment:
The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

----------------------------------------------------------------------

>Comment By: Matt Kraai (kraai)
Date: 2007-05-25 19:12

Message:
Logged In: YES 
user_id=1471342
Originator: YES

...and here's another revision.  This patch makes sys/termio.h be included
before termios.h in order to ensure that TCGETA, TCSETA, TCSETAW, and
TCSETAF can be used so that the termios module can be built, sets the stack
size to 2 megabytes so that test_compile.py doesn't overflow the stack, and
adds some comments to configure.in.

With it, the test suite can be run to completion, though there are still a
number of errors and failures.

Sorry for the churn.
File Added: patch

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-25 12:16

Message:
Logged In: YES 
user_id=849994
Originator: NO

Martin, will you take a look?

----------------------------------------------------------------------

Comment By: Matt Kraai (kraai)
Date: 2007-05-24 22:29

Message:
Logged In: YES 
user_id=1471342
Originator: YES

Here's an updated patch.  It's changed relative to the first one in that
it makes the workaround for the incompatibility between [n]curses.h and
stdlib.h be handled similar to how it's handled for other platforms, it
prevents _XOPEN_SOURCE from being defined to allow the socket module to
build, and it merges the QNX case for setting LDSHARED.

I tried to include the changes to configure and pyconfig.h.in, but that
made it too big.  If they need to be submitted, please let me how to do so.
File Added: patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

From noreply at sourceforge.net  Sat May 26 06:27:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 25 May 2007 21:27:22 -0700
Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from
	tokanize.c.
Message-ID: <E1HrnsA-0007Re-Gi@sc8-sf-web21.sourceforge.net>

Patches item #1720390, was opened at 2007-05-16 18:23
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Adam (ron_adam)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Remove backslash escapes from tokanize.c.

Initial Comment:

This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only.

A few strings needed changes in order to compile.  Two in textwrap.py, and one in distutils/util.py.

This does not include changes needed for tests to pass.  I'll include those in a separate patch.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-26 00:27

Message:
Logged In: YES 
user_id=6380
Originator: NO

Just FYI, I have downloaded this and will attempt to apply it some time
next week.

----------------------------------------------------------------------

Comment By: Ron Adam (ron_adam)
Date: 2007-05-19 22:15

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Here's a more complete patch which modifies the following files... (in
py3k_struni branch)

M      Python/ast.c
M      Parser/tokenizer.c
M      Lib/test/tokenize_tests.txt
M      Lib/tokenize.py

The test still dosen't pass, but it fails in the same way as it did before
these changes were made.  I'll continue to look into this.  I think it's
more of a problem with the test it self and not a problem with the modules.
 Or it may be a bug in the struni branch that is yet to be fixed.

The following alter one or two raw strings each replacing the outer most
quotes with triple quotes in most cases.

M      Lib/sgmllib.py
M      Lib/markupbase.py
M      Lib/textwrap.py
M      Lib/distutils/util.py
M      Lib/cookielib.py
M      Lib/pydoc.py
M      Lib/doctest.py
M      Lib/xml/etree/ElementTree.py
M      Lib/HTMLParser.py

File Added: norawescape2.diff

----------------------------------------------------------------------

Comment By: Ron Adam (ron_adam)
Date: 2007-05-19 22:14

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Here's a more complete patch which modifies the following files... (in
py3k_struni branch)

M      Python/ast.c
M      Parser/tokenizer.c
M      Lib/test/tokenize_tests.txt
M      Lib/tokenize.py

The test still dosen't pass, but it fails in the same way as it did before
these changes were made.  I'll continue to look into this.  I think it's
more of a problem with the test it self and not a problem with the modules.
 Or it may be a bug in the struni branch that is yet to be fixed.

The following alter one or two raw strings each replacing the outer most
quotes with triple quotes in most cases.

M      Lib/sgmllib.py
M      Lib/markupbase.py
M      Lib/textwrap.py
M      Lib/distutils/util.py
M      Lib/cookielib.py
M      Lib/pydoc.py
M      Lib/doctest.py
M      Lib/xml/etree/ElementTree.py
M      Lib/HTMLParser.py


----------------------------------------------------------------------

Comment By: Ron Adam (ron_adam)
Date: 2007-05-16 18:31

Message:
Logged In: YES 
user_id=1687923
Originator: YES

Forgot to specify...

This is against the py3k-struni branch, revision 55388.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470

From noreply at sourceforge.net  Sat May 26 20:39:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 11:39:50 -0700
Subject: [Patches] [ python-Patches-1726172 ] ftplib.py: IndexError in
	voidresp occasionally
Message-ID: <E1Hs1B8-0004vN-V3@sc8-sf-web21.sourceforge.net>

Patches item #1726172, was opened at 2007-05-26 20:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726172&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.py: IndexError in voidresp occasionally

Initial Comment:
A 1-char manual patch (still applies from 2.3 up to latest python trunk):


C:\Python23\Lib>diff -u org ftplib.py
--- org/ftplib.py       2002-06-03 11:41:46.000000000 +0200
+++ ftplib.py   2007-05-26 20:33:58.086219200 +0200
@@ -219,7 +219,7 @@
     def voidresp(self):
         """Expect a response beginning with '2'."""
         resp = self.getresp()
-        if resp[0] != '2':
+        if resp[:1] != '2':
             raise error_reply, resp
         return resp




--
it solves a rare:
  ...
  File "ftplib.pyo", line 386, in retrbinary 
  File "ftplib.pyo", line 222, in voidresp
IndexError: string index out of range




Robert

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726172&group_id=5470

From noreply at sourceforge.net  Sat May 26 22:09:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 13:09:19 -0700
Subject: [Patches] [ python-Patches-1726195 ] Patch to vs 2005 build
Message-ID: <E1Hs2Zj-0007Gr-Gu@sc8-sf-web24.sourceforge.net>

Patches item #1726195, was opened at 2007-05-26 16:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to vs 2005 build

Initial Comment:
As per the removal of the rgbimgmodule due to deprecation in the trunk:

http://svn.python.org/projects/python/trunk

---Begin SVN log---
r55458 | brett.cannon | 2007-05-20 03:09:50 -0400 (Sun, 20 May 2007) | 2 lines

Remove the rgbimg module.  It has been deprecated since Python 2.5.
---End SVN log---


The PCbuild8 solution needs to be corrected.  A patch is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

From noreply at sourceforge.net  Sat May 26 22:10:35 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 13:10:35 -0700
Subject: [Patches] [ python-Patches-1726196 ] Windows Build Warnings
Message-ID: <E1Hs2ax-0007Bm-By@sc8-sf-web22.sourceforge.net>

Patches item #1726196, was opened at 2007-05-26 16:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726196&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows Build Warnings

Initial Comment:
This patch will eliminate the .net 2005 WINVER build warnings due to #include ordering.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726196&group_id=5470

From noreply at sourceforge.net  Sat May 26 22:13:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 13:13:14 -0700
Subject: [Patches] [ python-Patches-1726198 ] Line iteration readability
Message-ID: <E1Hs2dW-0007wX-4a@sc8-sf-web21.sourceforge.net>

Patches item #1726198, was opened at 2007-05-26 16:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line iteration readability

Initial Comment:
I noticed there were several places that use the

while 1:

as opposed to the:

for line in fp:

approach to line-reading.  This patch takes care of some of them that I grep'd out.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

From noreply at sourceforge.net  Sat May 26 22:37:12 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 13:37:12 -0700
Subject: [Patches] [ python-Patches-1726208 ] SimpleHTTPServer extensions_map
Message-ID: <E1Hs30i-0001s5-Ey@sc8-sf-web24.sourceforge.net>

Patches item #1726208, was opened at 2007-05-26 16:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726208&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer extensions_map

Initial Comment:
This is reasonably minor, but questionable nevertheless.

Inside SimpleHTTPServer.py guess_type, it grabs the mimtypes types_map then updates it with .py, .c and .h...

Except, when I look in mimetypes.py, .py, .c and .h are part of the types_map.  No patch has been submitted here, but this will be quickly patchable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726208&group_id=5470

From noreply at sourceforge.net  Sun May 27 00:20:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 15:20:25 -0700
Subject: [Patches] [ python-Patches-1669481 ] subprocess: Support close_fds
	on Win32
Message-ID: <E1Hs4cb-0004MU-Rf@sc8-sf-web23.sourceforge.net>

Patches item #1669481, was opened at 2007-02-26 22:47
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jon Foster (jongfoster)
Assigned to: Peter ?strand (astrand)
Summary: subprocess: Support close_fds on Win32

Initial Comment:
There is an existing close_fds parameter to the subprocess.Popen() constructor that prevents FDs being copied to the child process on UNIX.  This patch makes that parameter also work on Windows (with a caveat).

Setting this parameter on Windows was explicitly prohibited by the code, because it prevents redirecting stdin/stdout/stderr.  However, the check is too restrictive; it is perfectly reasonable to set this flag if you are not redirecting anything.  That is what this patch does.

The behaviour is unchanged if you are on Windows, set this flag, and simultaneously try to redirect stdin/stdout/stderr: the call will fail with an exception.

This patch is against Python SVN trunk.

Kind regards,

Jon Foster


----------------------------------------------------------------------

>Comment By: Peter ?strand (astrand)
Date: 2007-05-27 00:20

Message:
Logged In: YES 
user_id=344921
Originator: NO

I've simplified the patch and applied it in revision 55604. Thanks. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-20 09:59

Message:
Logged In: YES 
user_id=33168
Originator: NO

Peter, could you take a look at this patch?

----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2007-04-23 15:53

Message:
Logged In: YES 
user_id=18139
Originator: NO

Patch looks good.  +1 (but I haven't tested it either).


----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-08 21:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

The patch looks good; unfortunately I don't have a Windows to test it,
otherwise I'd apply it.

----------------------------------------------------------------------

Comment By: Jon Foster (jongfoster)
Date: 2007-03-08 00:11

Message:
Logged In: YES 
user_id=199289
Originator: YES

I've been reading the general discussion on python-dev about patches
needing documentation and tests.  So here's an updated patch that includes
docs and tests.
File Added: subprocess_win32_close_handles_2.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470

From noreply at sourceforge.net  Sun May 27 08:21:10 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 23:21:10 -0700
Subject: [Patches] [ python-Patches-1726198 ] Line iteration readability
Message-ID: <E1HsC7q-0006LI-Bj@sc8-sf-web21.sourceforge.net>

Patches item #1726198, was opened at 2007-05-26 15:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line iteration readability

Initial Comment:
I noticed there were several places that use the

while 1:

as opposed to the:

for line in fp:

approach to line-reading.  This patch takes care of some of them that I grep'd out.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 01:21

Message:
Logged In: YES 
user_id=80475
Originator: NO

The patch is fine.  The first change should probably go a step further and
use enumerate() for the lineno counts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

From noreply at sourceforge.net  Sun May 27 08:39:28 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 26 May 2007 23:39:28 -0700
Subject: [Patches] [ python-Patches-1726198 ] Line iteration readability
Message-ID: <E1HsCPY-0000l1-7o@sc8-sf-web22.sourceforge.net>

Patches item #1726198, was opened at 2007-05-26 15:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line iteration readability

Initial Comment:
I noticed there were several places that use the

while 1:

as opposed to the:

for line in fp:

approach to line-reading.  This patch takes care of some of them that I grep'd out.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 01:39

Message:
Logged In: YES 
user_id=80475
Originator: NO

On second thought, the change to ConfigParse should not go in.  The docs
currently promise that any file-like object supporting readling() will be
accepted .

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-27 01:21

Message:
Logged In: YES 
user_id=80475
Originator: NO

The patch is fine.  The first change should probably go a step further and
use enumerate() for the lineno counts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726198&group_id=5470

From noreply at sourceforge.net  Sun May 27 17:06:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 27 May 2007 08:06:18 -0700
Subject: [Patches] [ python-Patches-1726451 ] ftplib and ProFTPD NLST 226
	without 1xx response
Message-ID: <E1HsKK2-0003O9-BL@sc8-sf-web21.sourceforge.net>

Patches item #1726451, was opened at 2007-05-27 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=305470&aid=1726451&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenneth Loafman (loafman)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib and ProFTPD NLST 226 without 1xx response

Initial Comment:
When ProFTPD and others do an NLST on an empty directory, they return a '226 Transfer Complete' without a 1xx response following (passive mode).  They also may reset the connection, producing a '104, Connection reset by peer'.  This patch corrects the 226 without 1xx response.  Due to bug reports on ProFTPD indicating that the connection reset may be their issue, this patch does not address that problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726451&group_id=5470

From noreply at sourceforge.net  Tue May 29 04:30:08 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 19:30:08 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1HsrTM-000701-9e@sc8-sf-web23.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Tue May 29 04:31:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 19:31:57 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1HsrV7-0007ij-Ez@sc8-sf-web24.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Tue May 29 05:22:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 20:22:03 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1HssHb-00014y-Hi@sc8-sf-web23.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:22

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version of the patch where C.f.im_class (in the above
example) correctly returns B.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Tue May 29 05:23:23 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 20:23:23 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1HssIt-0000Hk-Qq@sc8-sf-web21.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:23

Message:
Logged In: YES 
user_id=6380
Originator: YES

And a new sup.py example demonstrating that the new patch works.
File Added: sup.py

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:22

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version of the patch where C.f.im_class (in the above
example) correctly returns B.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Tue May 29 07:07:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 22:07:20 -0700
Subject: [Patches] [ python-Patches-1726195 ] Patch to vs 2005 build
Message-ID: <E1HstvU-0002xa-7y@sc8-sf-web24.sourceforge.net>

Patches item #1726195, was opened at 2007-05-26 22:09
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
>Assigned to: Kristj?n Valur (krisvale)
Summary: Patch to vs 2005 build

Initial Comment:
As per the removal of the rgbimgmodule due to deprecation in the trunk:

http://svn.python.org/projects/python/trunk

---Begin SVN log---
r55458 | brett.cannon | 2007-05-20 03:09:50 -0400 (Sun, 20 May 2007) | 2 lines

Remove the rgbimg module.  It has been deprecated since Python 2.5.
---End SVN log---


The PCbuild8 solution needs to be corrected.  A patch is attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

From noreply at sourceforge.net  Tue May 29 07:09:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 22:09:54 -0700
Subject: [Patches] [ python-Patches-1726687 ] Bug found in datetime for
	Epoch time = -1
Message-ID: <E1Hstxy-0003O0-0o@sc8-sf-web21.sourceforge.net>

Patches item #1726687, was opened at 2007-05-28 04:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726687&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin Blais (blais)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug found in datetime for Epoch time = -1

Initial Comment:
There is a bug in datetime.fromtimestamp(), whereby if it is called with -1, it fails with "mktime argument out of range" when it should not (see attached test program to reproduce the problem).

The bug is that the way that mktime() signals an error code is subtle and error-prone: you need to set a sentinel in the tm's wday or yday and not only check the return value of mktime, but also check if those values have been modified; it figures: -1 is a valid value in the return domain of mktime() and is not a sufficient condition for signaling an error.

Here is the relevant excerpt from the Linux man page:


       The mktime() function converts a broken-down time structure,  expressed
       as  local  time, to calendar time representation.  The function ignores
       the specified contents of the structure members tm_wday and tm_yday and
       recomputes  them  from  the  other  information in the broken-down time
       structure.  If structure members are outside their legal interval, they
       will  be normalized (so that, e.g., 40 October is changed into 9 Novem-
       ber).  Calling mktime() also sets the  external  variable  tzname  with
       information  about the current time zone.  If the specified broken-down
       time cannot be represented as calendar time (seconds since the  epoch),
       mktime() returns a value of (time_t)(-1) and does not alter the tm_wday
       and tm_yday members of the broken-down time structure.


This was found under Linux, I do not know if this bug also occurs on Windows or the Mac.

I attached a couple of files:

- timebug.py: reproduce the bug
- timebug.c: tests that mktime()'s behaviour is as wicked as expected
- timebug.patch: the fix to the datetime module.



P.S. I hit this bug in a graphics application while zooming in/out of a viewer rendering time-based data. Sheer luck.




----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-29 07:09

Message:
Logged In: YES 
user_id=21627
Originator: NO

Reclassifying as a patch.

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 04:38

Message:
Logged In: YES 
user_id=10996
Originator: YES

(Additional note: this bug was found and fixed with Peter Wang from
Enthought.)

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 04:30

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.patch

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 04:29

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.c

----------------------------------------------------------------------

Comment By: Martin Blais (blais)
Date: 2007-05-28 04:28

Message:
Logged In: YES 
user_id=10996
Originator: YES

File Added: timebug.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726687&group_id=5470

From noreply at sourceforge.net  Tue May 29 07:11:47 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 22:11:47 -0700
Subject: [Patches] [ python-Patches-1726668 ] platform.system() returns
	incorrect value in Vista
Message-ID: <E1Hstzn-0003bF-DM@sc8-sf-web21.sourceforge.net>

Patches item #1726668, was opened at 2007-05-28 03:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Leppard (bleppard)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: platform.system() returns incorrect value in Vista

Initial Comment:


On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows'

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'.

This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname().

This problem occurs in the trunk.

I have attached a patch against the trunk svn that fixes the symptom of the problem in uname()

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2007-05-29 07:11

Message:
Logged In: YES 
user_id=21627
Originator: NO

Reclassifying as a patch. Marc-Andre, can you take a look? If not, please
unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

From noreply at sourceforge.net  Tue May 29 08:08:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 28 May 2007 23:08:13 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1HsusP-0001vB-A9@sc8-sf-web23.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-29 02:08

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version.  Forget about sup.py, the demos are now in
Lib/test/test_super.py.

Only a few tests fail due to the semantic change (about six files have 1-2
failures each).  I think this is acceptable.

File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:23

Message:
Logged In: YES 
user_id=6380
Originator: YES

And a new sup.py example demonstrating that the new patch works.
File Added: sup.py

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:22

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version of the patch where C.f.im_class (in the above
example) correctly returns B.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Tue May 29 12:39:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 03:39:37 -0700
Subject: [Patches] [ python-Patches-1726195 ] Patch to vs 2005 build
Message-ID: <E1Hsz73-0002pE-Sh@sc8-sf-web21.sourceforge.net>

Patches item #1726195, was opened at 2007-05-26 20:09
Message generated for change (Comment added) made by krisvale
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Kristj?n Valur (krisvale)
Summary: Patch to vs 2005 build

Initial Comment:
As per the removal of the rgbimgmodule due to deprecation in the trunk:

http://svn.python.org/projects/python/trunk

---Begin SVN log---
r55458 | brett.cannon | 2007-05-20 03:09:50 -0400 (Sun, 20 May 2007) | 2 lines

Remove the rgbimg module.  It has been deprecated since Python 2.5.
---End SVN log---


The PCbuild8 solution needs to be corrected.  A patch is attached.

----------------------------------------------------------------------

>Comment By: Kristj?n Valur (krisvale)
Date: 2007-05-29 10:39

Message:
Logged In: YES 
user_id=1262199
Originator: NO

Fixed in trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726195&group_id=5470

From noreply at sourceforge.net  Tue May 29 18:08:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 09:08:43 -0700
Subject: [Patches] [ python-Patches-1726668 ] platform.system() returns
	incorrect value in Vista
Message-ID: <E1Ht4FX-0004Wk-Hl@sc8-sf-web23.sourceforge.net>

Patches item #1726668, was opened at 2007-05-28 03:23
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Leppard (bleppard)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform.system() returns incorrect value in Vista

Initial Comment:


On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows'

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'.

This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname().

This problem occurs in the trunk.

I have attached a patch against the trunk svn that fixes the symptom of the problem in uname()

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-29 18:08

Message:
Logged In: YES 
user_id=38388
Originator: NO

I don't have Vista handy to check the patch. 

Ideally, win32_ver() should be patched to return proper values for Vista
directly from the registry. Would be great if you could provide a patch for
this as well.

However, in some cases _syscmd_ver() will still be used, so the patch is
fine. Please add a comment explaining the problem and also add a check to
set release to 'Vista' in case the version starts with '6.0'.

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-29 07:11

Message:
Logged In: YES 
user_id=21627
Originator: NO

Reclassifying as a patch. Marc-Andre, can you take a look? If not, please
unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

From noreply at sourceforge.net  Tue May 29 20:32:56 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 11:32:56 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1Ht6V6-0007mC-ET@sc8-sf-web21.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 12:44
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 14:32

Message:
Logged In: YES 
user_id=984087
Originator: NO


Can you tell the exact command you ran to get the above output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Tue May 29 21:07:02 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 12:07:02 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1Ht726-0002GG-IU@sc8-sf-web22.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 19:44
Message generated for change (Comment added) made by betelgeus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

>Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-29 22:07

Message:
Logged In: YES 
user_id=924568
Originator: YES

python setup.py sdist --formats=bztar

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 21:32

Message:
Logged In: YES 
user_id=984087
Originator: NO


Can you tell the exact command you ran to get the above output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Tue May 29 23:58:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 14:58:46 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1Ht9iI-0007Mn-JO@sc8-sf-web23.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 12:44
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 17:58

Message:
Logged In: YES 
user_id=984087
Originator: NO

I tested with latest built python on Linux but couldn't reproduce the
problem. I created directories .svn in distribution root directory as well
as under "foobar". Both of them got skipped. It will be helpful if you can
create a very small distribution manifesting reported problem and upload
tar.gz file here. I can then give a try using that distribution.

----------------------------------------------------------------------

Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-29 15:07

Message:
Logged In: YES 
user_id=924568
Originator: YES

python setup.py sdist --formats=bztar

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 14:32

Message:
Logged In: YES 
user_id=984087
Originator: NO


Can you tell the exact command you ran to get the above output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Wed May 30 00:04:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 15:04:46 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1Ht9o6-0000Y3-K7@sc8-sf-web23.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 19:44
Message generated for change (Comment added) made by betelgeus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

>Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-30 01:04

Message:
Logged In: YES 
user_id=924568
Originator: YES

Did you use global-include * in MANIFEST.in?


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 00:58

Message:
Logged In: YES 
user_id=984087
Originator: NO

I tested with latest built python on Linux but couldn't reproduce the
problem. I created directories .svn in distribution root directory as well
as under "foobar". Both of them got skipped. It will be helpful if you can
create a very small distribution manifesting reported problem and upload
tar.gz file here. I can then give a try using that distribution.

----------------------------------------------------------------------

Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-29 22:07

Message:
Logged In: YES 
user_id=924568
Originator: YES

python setup.py sdist --formats=bztar

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 21:32

Message:
Logged In: YES 
user_id=984087
Originator: NO


Can you tell the exact command you ran to get the above output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Wed May 30 00:06:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 15:06:05 -0700
Subject: [Patches] [ python-Patches-1725737 ] Distutils default exclude
	doesn't match top level .svn
Message-ID: <E1Ht9pN-0006AO-2Y@sc8-sf-web21.sourceforge.net>

Patches item #1725737, was opened at 2007-05-25 12:44
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Petteri R?ty (betelgeus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Distutils default exclude doesn't match top level .svn

Initial Comment:
betelgeuse at pena ~/java-config-trunk $ cat MANIFEST.in 
global-include *
prune make-release

Gives me:
hard linking .svn/all-wcprops -> java-config-2.0.33/.svn
hard linking .svn/dir-prop-base -> java-config-2.0.33/.svn
hard linking .svn/entries -> java-config-2.0.33/.svn
hard linking .svn/format -> java-config-2.0.33/.svn
hard linking .svn/prop-base/make-release.svn-base -> java-config-2.0.33/.svn/prop-base
hard linking .svn/text-base/AUTHORS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/MANIFEST.in.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/NEWS.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/TODO.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/make-release.svn-base -> java-config-2.0.33/.svn/text-base
hard linking .svn/text-base/setup.py.svn-base -> java-config-2.0.33/.svn/text-base

The documentation on the other hand says:
          * any RCS, CVS and .svn directories


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 18:06

Message:
Logged In: YES 
user_id=984087
Originator: NO

I did.

----------------------------------------------------------------------

Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-29 18:04

Message:
Logged In: YES 
user_id=924568
Originator: YES

Did you use global-include * in MANIFEST.in?


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 17:58

Message:
Logged In: YES 
user_id=984087
Originator: NO

I tested with latest built python on Linux but couldn't reproduce the
problem. I created directories .svn in distribution root directory as well
as under "foobar". Both of them got skipped. It will be helpful if you can
create a very small distribution manifesting reported problem and upload
tar.gz file here. I can then give a try using that distribution.

----------------------------------------------------------------------

Comment By: Petteri R?ty (betelgeus)
Date: 2007-05-29 15:07

Message:
Logged In: YES 
user_id=924568
Originator: YES

python setup.py sdist --formats=bztar

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-29 14:32

Message:
Logged In: YES 
user_id=984087
Originator: NO


Can you tell the exact command you ran to get the above output?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1725737&group_id=5470

From noreply at sourceforge.net  Wed May 30 08:04:25 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 29 May 2007 23:04:25 -0700
Subject: [Patches] [ python-Patches-1726668 ] platform.system() returns
	incorrect value in Vista
Message-ID: <E1HtHIH-0000J6-6T@sc8-sf-web23.sourceforge.net>

Patches item #1726668, was opened at 2007-05-27 21:23
Message generated for change (Comment added) made by bleppard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Leppard (bleppard)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform.system() returns incorrect value in Vista

Initial Comment:


On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows'

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'.

This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname().

This problem occurs in the trunk.

I have attached a patch against the trunk svn that fixes the symptom of the problem in uname()

----------------------------------------------------------------------

>Comment By: Benjamin Leppard (bleppard)
Date: 2007-05-30 02:04

Message:
Logged In: YES 
user_id=1802829
Originator: YES

I updated the patch to included comments, and set the release to 'Vista'
when the version starts with '6.0'. Unfortunately both Windows Server 2008
and Windows Vista both are version 6.0.

I updated win32_ver() to report the correct values for Vista and Windows
Server 2008. It reports release of '2008Server' for Windows 2008 server,
and release of 'post2008Server' for version 6.1 or greater. I have not
tested it under Windows Server 2008.
File Added: Platform-VistaFix2.patch

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-29 12:08

Message:
Logged In: YES 
user_id=38388
Originator: NO

I don't have Vista handy to check the patch. 

Ideally, win32_ver() should be patched to return proper values for Vista
directly from the registry. Would be great if you could provide a patch for
this as well.

However, in some cases _syscmd_ver() will still be used, so the patch is
fine. Please add a comment explaining the problem and also add a check to
set release to 'Vista' in case the version starts with '6.0'.

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2007-05-29 01:11

Message:
Logged In: YES 
user_id=21627
Originator: NO

Reclassifying as a patch. Marc-Andre, can you take a look? If not, please
unassign.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470

From noreply at sourceforge.net  Wed May 30 09:00:03 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 00:00:03 -0700
Subject: [Patches] [ python-Patches-1713234 ] Fix warnings related to
	PyLong_FromVoidPtr
Message-ID: <E1HtIA7-0006Jr-Ht@sc8-sf-web23.sourceforge.net>

Patches item #1713234, was opened at 2007-05-05 04:35
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713234&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
>Status: Closed
Resolution: None
Priority: 3
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix warnings related to PyLong_FromVoidPtr

Initial Comment:
This is slight fix.
PyLong_FromVoidPtr(void *) causes warning on
Modules/_ctypes/callbacks.c (line 387)
> PyObject *py_rclsid = PyLong_FromVoidPtr(rclsid);
>>>> this gets rid of constness of void pointer


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2007-05-30 09:00

Message:
Logged In: YES 
user_id=11105
Originator: NO

I added the explicit casts in the source code, that should make the
warnings go away.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2007-05-05 18:38

Message:
Logged In: YES 
user_id=11105
Originator: NO

The compiler warnings in Modules/_ctypes/callbacks.c are easily fixed by
adding explicit casts:

		PyObject *py_rclsid = PyLong_FromVoidPtr((void *)rclsid);
		PyObject *py_riid = PyLong_FromVoidPtr((void *)riid);

On the other hand, IMO it makes sense to change the signature of
PyLong_FromVoidPtr to accept 'const void *' pointers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713234&group_id=5470

From noreply at sourceforge.net  Wed May 30 15:16:27 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 06:16:27 -0700
Subject: [Patches] [ python-Patches-1722225 ] Build on QNX
Message-ID: <E1HtO2N-0007MS-Ab@sc8-sf-web24.sourceforge.net>

Patches item #1722225, was opened at 2007-05-20 10:11
Message generated for change (Comment added) made by kraai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Kraai (kraai)
Assigned to: Martin v. L?wis (loewis)
Summary: Build on QNX

Initial Comment:
The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

----------------------------------------------------------------------

>Comment By: Matt Kraai (kraai)
Date: 2007-05-30 06:16

Message:
Logged In: YES 
user_id=1471342
Originator: YES

Here's a new patch.  It differs from the previous version in that it
excludes nis from the list of modules to be built (since QNX does not
provide the necessary header files) and allows the ctypes module to be
built.  Since it modifies libffi's configure.ac, autoconf must be run to
regenerate its configure also.
File Added: patch

----------------------------------------------------------------------

Comment By: Matt Kraai (kraai)
Date: 2007-05-25 19:12

Message:
Logged In: YES 
user_id=1471342
Originator: YES

...and here's another revision.  This patch makes sys/termio.h be included
before termios.h in order to ensure that TCGETA, TCSETA, TCSETAW, and
TCSETAF can be used so that the termios module can be built, sets the stack
size to 2 megabytes so that test_compile.py doesn't overflow the stack, and
adds some comments to configure.in.

With it, the test suite can be run to completion, though there are still a
number of errors and failures.

Sorry for the churn.
File Added: patch

----------------------------------------------------------------------

Comment By: Georg Brandl (gbrandl)
Date: 2007-05-25 12:16

Message:
Logged In: YES 
user_id=849994
Originator: NO

Martin, will you take a look?

----------------------------------------------------------------------

Comment By: Matt Kraai (kraai)
Date: 2007-05-24 22:29

Message:
Logged In: YES 
user_id=1471342
Originator: YES

Here's an updated patch.  It's changed relative to the first one in that
it makes the workaround for the incompatibility between [n]curses.h and
stdlib.h be handled similar to how it's handled for other platforms, it
prevents _XOPEN_SOURCE from being defined to allow the socket module to
build, and it merges the QNX case for setting LDSHARED.

I tried to include the changes to configure and pyconfig.h.in, but that
made it too big.  If they need to be submitted, please let me how to do so.
File Added: patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1722225&group_id=5470

From noreply at sourceforge.net  Wed May 30 17:49:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 08:49:34 -0700
Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first
	char of default package
Message-ID: <E1HtQQY-0006z0-C0@sc8-sf-web22.sourceforge.net>

Patches item #1183712, was opened at 2005-04-15 08:34
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: package_data chops off first char of default package

Initial Comment:
If the package name is an empty string (ie the default
package), all package_data files have the first
character chopped off.
Attached is a test package pytest.tar.gz where running
python2.4 setup.py build_py
produces this error:
running build_py
creating build
creating build/lib
copying __init__.py -> build/lib
error: can't copy 'ATA': doesn't exist or not a regular
file

Also attached is a fix proposal, though I have tested
this only against the test package.


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 11:49

Message:
Logged In: YES 
user_id=984087
Originator: NO


Please check patch 1720897 which fixes slightly related problem.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-02-23 17:07

Message:
Logged In: YES 
user_id=56214
Originator: NO

I concur with Martin: setup() should disallow an empty string as a
package, because an empty string is not a valid Python package name.

Regarding Jim's comment that the stripping should be smarter, I'd like to
point out that package_dirs must only contain platform-independent
directory names, and if anything else is included, it will produce an error
when the build_py command is initialized, as 'convert_path' is called on
the paths in question.  Thus, they can never contain absolute paths or end
in a trailing /.

Thus, the only problem here is that packages is allowed to contain empty
strings, which it makes no sense to include.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-31 09:26

Message:
Logged In: YES 
user_id=764593

I think the patch is still missing a case or two.  

plen represents the length of the path prefix to ignore.  

Today's code computes this as (len(src_dir) + 1) where the 
+1 is for the "/" added by os.path.join().  As you found, 
src_dir won't add anything (including the "/") if src_dir 
is empty.  

But it also won't add the "/" if src_dir already ends in "/
", and it won't even add the src_dir if the path is already 
absolute.

I'm not certain that either of these two cases can occur, 
but it would be safer to assume they can.

My suggestion is that the stripping be smarter -- change

"""
            # Strip directory from globbed filenames
            filenames = [
                file[plen:] for file in 
self.find_data_files(package, src_dir)
                ]
"""

to 

"""
            # Strip directory from globbed filenames
            filenames = [
                filetail(name, src_dir) for name in 
self.find_data_files(package, src_dir)
                ]
"""
where filetail is a helper function defined as
"""
def filetail(name, strip_path):
    if name.startswith(strip_path):
        kill=len(strip_path)
        if name[kill] == "/":
            kill +=1
        name=name[kill:]
    return name
"""
with tests
"""
>>> filetail("asdf/bdededf", "asdf")
'bdededf'
>>> filetail("asdf/bdededf", "asdf/")
'bdededf'    
"""



----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2006-05-22 16:13

Message:
Logged In: YES 
user_id=9205

I found it in another Python program (don't remember which
though). So I did not think of this as an undocumented
feature. I tried it and it worked (except the data file
stuff :).

The patch should not break any currently working setup.py
installation, since src_dir is only empty when using ''
(empty string) as package name.

Perhaps a cleaner approach would be to forbid an empty
package name instead of silently accepting it? I am not
sure. At least the documentation should mention that empty
package names are not allowed.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2006-04-15 04:23

Message:
Logged In: YES 
user_id=21627

Why are you using an empty name as the package name? There
is no default package in Python, so this shouldn't work at all.

----------------------------------------------------------------------

Comment By: Herv? Cauwelier (hcauwelier)
Date: 2005-10-05 07:03

Message:
Logged In: YES 
user_id=1216236

The patch worked well for me, thanks for it!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470

From noreply at sourceforge.net  Wed May 30 18:31:40 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 09:31:40 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtR5I-0004wr-L4@sc8-sf-web22.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 18:13
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 16:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 18:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 18:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 18:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 18:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 19:19:22 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 10:19:22 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtRpS-0008DJ-9P@sc8-sf-web23.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 13:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 12:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 19:58:41 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 10:58:41 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtSRV-0007gR-7v@sc8-sf-web24.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 15:13
Message generated for change (Comment added) made by errebepe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 14:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 14:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 13:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 21:00:37 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 12:00:37 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtTPR-0007b4-TY@sc8-sf-web23.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 15:00

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, Thanks for the comments. I incorporated your suggestions about
the test case. It will now check explicitly for DistutilsFileError and
calls self.fail() if it gets this exception. I removed parens in "if
(src_dir)" as well.

I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it
difficult to follow compared to an explicit "if".

As to adding a docstring to the test case, I vaguely remember seeing some
comment about not having docstrings in test functions. I also don't find
docstrings in any of the test functions (found with a quick look at less
test_*.py output).





----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 13:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 13:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 12:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 21:01:50 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 12:01:50 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtTQc-0007iU-Ly@sc8-sf-web23.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 15:01

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 15:00

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, Thanks for the comments. I incorporated your suggestions about
the test case. It will now check explicitly for DistutilsFileError and
calls self.fail() if it gets this exception. I removed parens in "if
(src_dir)" as well.

I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it
difficult to follow compared to an explicit "if".

As to adding a docstring to the test case, I vaguely remember seeing some
comment about not having docstrings in test functions. I also don't find
docstrings in any of the test functions (found with a quick look at less
test_*.py output).





----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 13:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 13:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 12:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 21:42:21 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 12:42:21 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtU3p-0006B5-Dm@sc8-sf-web24.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 15:13
Message generated for change (Comment added) made by errebepe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 16:42

Message:
Logged In: YES 
user_id=374783
Originator: NO

True, I couldn't find many tests with docstrings either (though there are
a few: find -name test_\*.py -exec egrep -nHB1 '^\s*"""' {} \; | grep -C1
'def test_' | less). On the other hand, most test names are somewhat
descriptive of what they are testing. I think a brief description, either
in a docstring or in a regular comment (which are common in existing
tests), would be helpful to anyone reading it later.

As for the rest, great! Thanks for the patch and for the quick response :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 16:01

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 16:00

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, Thanks for the comments. I incorporated your suggestions about
the test case. It will now check explicitly for DistutilsFileError and
calls self.fail() if it gets this exception. I removed parens in "if
(src_dir)" as well.

I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it
difficult to follow compared to an explicit "if".

As to adding a docstring to the test case, I vaguely remember seeing some
comment about not having docstrings in test functions. I also don't find
docstrings in any of the test functions (found with a quick look at less
test_*.py output).





----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 14:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 14:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 13:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 22:50:49 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 13:50:49 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtV85-0006ic-2G@sc8-sf-web22.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 14:13
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

>Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 16:50

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, I added a comment to the test case. I need some more time to
analyze your find command but that is not relevant to this patch :-).
File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 15:42

Message:
Logged In: YES 
user_id=374783
Originator: NO

True, I couldn't find many tests with docstrings either (though there are
a few: find -name test_\*.py -exec egrep -nHB1 '^\s*"""' {} \; | grep -C1
'def test_' | less). On the other hand, most test names are somewhat
descriptive of what they are testing. I think a brief description, either
in a docstring or in a regular comment (which are common in existing
tests), would be helpful to anyone reading it later.

As for the rest, great! Thanks for the patch and for the quick response :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 15:01

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 15:00

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, Thanks for the comments. I incorporated your suggestions about
the test case. It will now check explicitly for DistutilsFileError and
calls self.fail() if it gets this exception. I removed parens in "if
(src_dir)" as well.

I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it
difficult to follow compared to an explicit "if".

As to adding a docstring to the test case, I vaguely remember seeing some
comment about not having docstrings in test functions. I also don't find
docstrings in any of the test functions (found with a quick look at less
test_*.py output).





----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 13:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 13:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 12:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 14:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 14:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Wed May 30 23:10:14 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 14:10:14 -0700
Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles
	properly when package_dir is ' '
Message-ID: <E1HtVQs-0001Yk-C2@sc8-sf-web22.sourceforge.net>

Patches item #1720897, was opened at 2007-05-17 15:13
Message generated for change (Comment added) made by errebepe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils and setup.py
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix 1668596: copy datafiles properly when package_dir is ' '

Initial Comment:

This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names.

I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me.

----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 18:10

Message:
Logged In: YES 
user_id=374783
Originator: NO

Looks great!

I don't mean to sound picky, but I think the comment should go inside the
method definition. PEP8 says "Block comments generally apply to some (or
all) code that follows them, and are indented to the same level as that
code."

But, really, now I'm just fine-tuning, the patch is fine as far as I'm
concerned :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 17:50

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, I added a comment to the test case. I need some more time to
analyze your find command but that is not relevant to this patch :-).
File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 16:42

Message:
Logged In: YES 
user_id=374783
Originator: NO

True, I couldn't find many tests with docstrings either (though there are
a few: find -name test_\*.py -exec egrep -nHB1 '^\s*"""' {} \; | grep -C1
'def test_' | less). On the other hand, most test names are somewhat
descriptive of what they are testing. I think a brief description, either
in a docstring or in a regular comment (which are common in existing
tests), would be helpful to anyone reading it later.

As for the rest, great! Thanks for the patch and for the quick response :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 16:01

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 16:00

Message:
Logged In: YES 
user_id=984087
Originator: YES


errebepe, Thanks for the comments. I incorporated your suggestions about
the test case. It will now check explicitly for DistutilsFileError and
calls self.fail() if it gets this exception. I removed parens in "if
(src_dir)" as well.

I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it
difficult to follow compared to an explicit "if".

As to adding a docstring to the test case, I vaguely remember seeing some
comment about not having docstrings in test functions. I also don't find
docstrings in any of the test functions (found with a quick look at less
test_*.py output).





----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-30 14:58

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the fix.

I do have a few minor suggestions, however. In the fix itself, the parens
in "(src_dir)" are still there. If the fix will only be applied in >= 2.5,
you might also use the "plen = len(src_dir)+1 if src_dir else 0" form.

As for the test, since you're testing a very specific error scenario
(Distribution.run_commands raising DistutilsFileError), I'd suggest
catching the exception and using "self.fail", so that testing the unfixed
code fails instead of issues an error. Since you expect the error to occur
inside run_commands, I'd put the try...except block around the
"dist.run_commands()" only, as in:

# Auxiliary variable, since you need cleanup and self.fail exits before
"finally":
error = False
try:
....dist.run_commands()
except DistutilsFileError:
....error = True
finally:
....os.chdir(cwd)
if error:
....self.fail("run_commands fails with no package_dir")

Gustavo Niemeyer also mentioned you should add a dosctring to the test
explaining what exactly it's testing.

To sum it up, I recommend commit of this patch regardless of my comments
above, but I hope they're taken into consideration :)

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-30 14:19

Message:
Logged In: YES 
user_id=984087
Originator: YES

Thanks for reviewing. As for parens, they don't exist in the current
patch. Right? I removed them quite some time back.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2007-05-30 13:31

Message:
Logged In: YES 
user_id=56214
Originator: NO

+1 on this approach; recommend commit of this patch (note, however, that
the parens in "if (src_dir):" are redundant).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:24

Message:
Logged In: YES 
user_id=984087
Originator: YES


I managed to create a test case (is part of the patch now). I ran it on
Linux and Windows XP and in both cases, it properly tests the problem. 


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-21 15:22

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: buildpy_patch.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:25

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: build_py.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 15:17

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: 1668596_test.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470

From noreply at sourceforge.net  Thu May 31 05:06:05 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 20:06:05 -0700
Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects
	pprint's handling of 'depth'
Message-ID: <E1HtazF-0006ba-Si@sc8-sf-web22.sourceforge.net>

Patches item #1713041, was opened at 2007-05-04 16:13
Message generated for change (Comment added) made by errebepe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for 1712742: corrects pprint's handling of 'depth'

Initial Comment:

The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug.



----------------------------------------------------------------------

Comment By: Rodrigo Bernardo Pimentel (errebepe)
Date: 2007-05-31 00:06

Message:
Logged In: YES 
user_id=374783
Originator: NO

+1 on the patch (test, code and doc). In particular, if depth == 0 is not
allowed, I think the patched behaviour is the expected one, so this is
actually a bug fix rather than a change in the module's semantic. 

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-18 18:16

Message:
Logged In: YES 
user_id=984087
Originator: YES

Neal, is there anything else you want me to do for the patch?

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 12:09

Message:
Logged In: YES 
user_id=984087
Originator: YES

josm, please feel free to go to python-dev if you think community input is
required. I personally don't think that it is warranted.

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-13 09:14

Message:
Logged In: YES 
user_id=1776568
Originator: NO

What is intuitive is a matter of taste.
Some people like to count from zero, like many programmers do.

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-13 08:56

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, merely changing (fixing) the handling of "depth" parameter is not a
spec change. The patch makes pprint behave in a way that is intuitive from
the meaning of "depth".

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-12 11:09

Message:
Logged In: YES 
user_id=1776568
Originator: NO

 Yes, the doc seems to be wrong, and I agree with you 
changing wrong doc is always right thing to do, 
but this patch changed the way how pprint handles 'depth'. 

 I think I can call this as 'a spec change'.
changing some existent module's behavior is 
something that needs to be done carefully.

Don't we need a consensus among community?

No one cares so much how pprint works?
could be ...

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 18:41

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm> I just thought if changing the doc itself would cause 
josm> some problem, we have to fix the code to work the way 
josm> the doc says.

Not if the doc is wrong. 

josm> Don't we have to get someone's approval to change the 
josm> spec?

We are not changing the spec here.



----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 18:37

Message:
Logged In: YES 
user_id=1776568
Originator: NO

That test case was for pp2.diff.

I just thought if changing the doc itself would cause some problem,
we have to fix the code to work the way the doc says.

Don't we have to get someone's approval to change the spec?



----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 11:13

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint.patch

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-10 11:13

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, I don't think there is need for a new test case. The one in the
patch correctly tests the code change. As Neal pointed out, the doc is
wrong to begin with. 

I updated the patch with the doc change. Note that I replaced the current
example with a very simple one. I believe the current one is overly
complicated for this purpose. Comments are welcome, of course. 

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-10 08:56

Message:
Logged In: YES 
user_id=1776568
Originator: NO

I agree. The code and the doc should be consistent.

New test would be

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55223)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,27 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
repr(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), repr(nested_list))
+
+        result_tuple = {'lv1': '(...)',
+                        'lv2': '(1, (...))'}
+        result_dict = {'lv1': '{...}',
+                       'lv2': '{1: {...}}'}
+        result_list = {'lv1': '[...]',
+                       'lv2': '[1, [...]]'}
+        for i in [1, 2]:
+            key = 'lv' + `i`
+            self.assertEqual(pprint.pformat(nested_tuple, depth=i),
result_tuple[key])
+            self.assertEqual(pprint.pformat(nested_dict, depth=i),
result_dict[key])
+            self.assertEqual(pprint.pformat(nested_list, depth=i),
result_list[key])
+
 class DottedPrettyPrinter(pprint.PrettyPrinter):
 
     def format(self, object, context, maxlevels, level):


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-10 03:18

Message:
Logged In: YES 
user_id=33168
Originator: NO

Yes, that's the example I'm referring to.  In the doc, it shows 5 numbers
and one ... for 6.  Without your patch it shows 7 numbers and with your
patch it shows 6 numbers.  So even with your patch the doc and code don't
agree (they are off by one, rather than 2 as is currently the case).

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-09 11:44

Message:
Logged In: YES 
user_id=984087
Originator: YES


Hi Neal,

I assume you are referring to the example 

>>> import parser
>>> tup = parser.ast2tuple(
...     parser.suite(open('pprint.py').read()))[1][1][1]
>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint(tup)

in the document. Is that correct? I ran this example with and without my
patch. Without the update, the example printed 7 levels which is one level
too deep. With the patch, it printed 6 levels, which seems correct to me.

# without patch. prints 7 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (306, (...))))))))

# with patch. prints 6 levels.
$ ../python/python testdoc.py 
(268, (269, (326, (303, (304, (305, (...)))))))

I am attaching the file testdoc.py which contains the doc example. I just
wanted to confirm that this is what you are referring to.




File Added: testdoc.py

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-09 03:56

Message:
Logged In: YES 
user_id=33168
Originator: NO

I notice in the doc an example which doesn't work with this patch.  It
still prints one level too deep.  The doc seems correct to me, but I don't
have strong feelings any way.  The attached patch makes the doc example
work as expected.  The doc should really be updated with an example more
like:

>>> pp = pprint.PrettyPrinter(depth=6)
>>> pp.pprint((1, (2, (3, (4, (5, (6, 7)))))))
(1, (2, (3, (4, (5, (...))))))
>>> pp = pprint.PrettyPrinter(depth=1)
>>> pp.pprint(1)
1
>>> pp.pprint([1])
[...]

The updated patch causes the new tests to fail.  Could you update the
test/code/doc to all be consistent?
File Added: pp2.diff

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-07 11:49

Message:
Logged In: YES 
user_id=984087
Originator: YES


josm, thanks for the test case. I incorporated it into the patch. BTW, I
changed "str" to "repr" as I think "repr" is closer to what pformat does.
File Added: pprint.patch

----------------------------------------------------------------------

Comment By: jos (josm)
Date: 2007-05-05 06:02

Message:
Logged In: YES 
user_id=1776568
Originator: NO

Your patch looks good and worked fine.

Wouldn't it be nice to add a test case for this problem to
test_pprint.py?
The following is just draft patch to add the test case.

Index: Lib/test/test_pprint.py
===================================================================
--- Lib/test/test_pprint.py	(revision 55144)
+++ Lib/test/test_pprint.py	(working copy)
@@ -195,7 +195,22 @@
  others.should.not.be: like.this}"""
         self.assertEqual(DottedPrettyPrinter().pformat(o), exp)
 
+    def test_depth(self):
+        nested_tuple = (1, (2, (3, (4, (5, 6)))))
+        nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}}
+        nested_list = [1, [2, [3, [4, [5, [6, []]]]]]]
 
+        self.assertEqual(pprint.pformat(nested_tuple),
str(nested_tuple))
+        self.assertEqual(pprint.pformat(nested_dict), str(nested_dict))
+        self.assertEqual(pprint.pformat(nested_list), str(nested_list))
+
+        lv1_tuple = '(1, (...))'
+        lv1_dict = '{1: {...}}'
+        lv1_list = '[1, [...]]'
+        self.assertEqual(pprint.pformat(nested_tuple, depth=1),
lv1_tuple)
+        self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict)
+        self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list)
+


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-04 16:15

Message:
Logged In: YES 
user_id=984087
Originator: YES

File Added: pprint_test.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470

From noreply at sourceforge.net  Thu May 31 08:29:11 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 30 May 2007 23:29:11 -0700
Subject: [Patches] [ python-Patches-1728741 ] move intern to sys,
	make intern() optionally warn
Message-ID: <E1Hte9n-0005eK-Uc@sc8-sf-web24.sourceforge.net>

Patches item #1728741, was opened at 2007-05-31 16:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1728741&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Neal Norwitz (nnorwitz)
Summary: move intern to sys, make intern() optionally warn

Initial Comment:
This patch moves intern() to sys.intern(). intern() will still work - it optionally issues a warning (based on the 3.x compat flag) then calls across to sys.intern()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1728741&group_id=5470

From noreply at sourceforge.net  Thu May 31 13:24:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 31 May 2007 04:24:30 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1Htila-00062T-Au@sc8-sf-web23.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-31 07:24

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a version that modifies the grammar so 'super' is a keyword. The
compiler automatically inserts a 'super' keyword-only argument into a
function's signature when the 'super' keyword is used in its body.  It
works!

This requires the p3yk branch at -r55692 or newer.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-29 02:08

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version.  Forget about sup.py, the demos are now in
Lib/test/test_super.py.

Only a few tests fail due to the semantic change (about six files have 1-2
failures each).  I think this is acceptable.

File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:23

Message:
Logged In: YES 
user_id=6380
Originator: YES

And a new sup.py example demonstrating that the new patch works.
File Added: sup.py

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:22

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version of the patch where C.f.im_class (in the above
example) correctly returns B.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

From noreply at sourceforge.net  Thu May 31 13:45:18 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 31 May 2007 04:45:18 -0700
Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super
	(PEP 367)
Message-ID: <E1Htj5i-0002rt-EF@sc8-sf-web22.sourceforge.net>

Patches item #1727209, was opened at 2007-05-28 22:30
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: First steps towards new super (PEP 367)

Initial Comment:
A half-assed start of an implementation for super.

This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g.

def foo(self, arg, *, super):
    return super.foo(arg) + 1

Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup.  E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C.  (I hope to this in a later version.)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-31 07:45

Message:
Logged In: YES 
user_id=6380
Originator: YES

Oops, a last-minute change didn't work out.  This version is better.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-31 07:24

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a version that modifies the grammar so 'super' is a keyword. The
compiler automatically inserts a 'super' keyword-only argument into a
function's signature when the 'super' keyword is used in its body.  It
works!

This requires the p3yk branch at -r55692 or newer.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-29 02:08

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version.  Forget about sup.py, the demos are now in
Lib/test/test_super.py.

Only a few tests fail due to the semantic change (about six files have 1-2
failures each).  I think this is acceptable.

File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:23

Message:
Logged In: YES 
user_id=6380
Originator: YES

And a new sup.py example demonstrating that the new patch works.
File Added: sup.py

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 23:22

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a new version of the patch where C.f.im_class (in the above
example) correctly returns B.
File Added: super.diff

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-05-28 22:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here is sup.py, a small demo of how this is supposed to work.
File Added: sup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470