[ python-Bugs-869197 ] setgroups rejects long integer arguments

[SourceForge.net]

Bugs item #869197, was opened at 2004-01-02 10:38
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&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: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: setgroups rejects long integer arguments

Initial Comment:
os.setgroups ought to accept long integer arguments,
just as os.setgid does.  I think this worked in an
earlier version of Python - or maybe it was that
string.atol used to return a non-long integer if the
number was small enough, so I didn't encounter long
integers at all.

>>> import os
>>> os.setgid(1L)
>>> os.setgroups((1L,))
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: groups must be integers
>>> import sys
>>> print sys.version
2.3.3 (#1, Dec 30 2003, 22:52:56) 
[GCC 3.2.3]


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 09:44

Message:
Logged In: YES 
user_id=1188172

Adding enhanced patch.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-10-02 10:52

Message:
Logged In: YES 
user_id=21627

Would that be the time to check that the value fits into a
gid_t? 

I think the strategy would be this:
- assign the value to grouplist[i]
- read it back again
- check if this is still the same value



--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-29 22:36

Message:
Logged In: YES 
user_id=1188172

Attaching patch against CVS head. Please review.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values

[SourceForge.net]

Bugs item #1281408, was opened at 2005-09-04 00:12
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&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: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Martin v. Löwis (loewis)
Summary: Py_BuildValue k format units don't work with big values

Initial Comment:
Python 2.4 on Windows XP SP2

Consider this code:

unsigned long x = 0xaabbccdd;
PyObject* v = Py_BuildValue("k", x);
unsigned long y = PyLong_AsUnsignedLong(v);

y will be equal with -1 because PyLong_AsUnsignedLong
will raise an OverflowError since Py_BuildValue doesn't
create a long for the "k" format unit, but an int which
will be interpreted as a negative number.

The K format seems to have the same error,
PyLong_FromLongLong is used instead of
PyLong_FromUnsignedLongLong.

The do_mkvalue function from mod_support.c must be
fixed to use PyLong_FromUnsignedLong instead of
PyInt_FromLong for "k".

Also, the BHLkK  format units for Py_BuildValue should
be documented. In my Python 2.4 manual they do not appear.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 09:45

Message:
Logged In: YES 
user_id=1188172

Ping!

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-18 12:07

Message:
Logged In: YES 
user_id=1188172

Attaching patch (including doc changes). For I and k, it
creates an int if it fits, else a long.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-09-18 10:59

Message:
Logged In: YES 
user_id=21627

I'm not sure what it should do: the other option would be to
create an int if it fits, else a long. For 2.4.x atleast,
this would give better backwards compatibility given the
status quo.

I certainly agree that the documentation should be updated.
Patches are welcome.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-14 22:02

Message:
Logged In: YES 
user_id=1188172

I think you're right. Do you too, Martin?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1350498 ] CVS migration not in www.python.org docs

[SourceForge.net]

Bugs item #1350498, was opened at 2005-11-07 17:52
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&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
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Brett Cannon (bcannon)
Summary: CVS migration not in www.python.org docs

Initial Comment:
The development head has recently moved from 
CVS on sourceforge to subversion on python.org.

The www.python.org documentation still sends 
people to the sourceforge cvs via

(1)  The left hand navigation link (main page) under 
Documenation section, python project, cvs.  (The 
similar link on http://www.python.org/dev/ has been 
updated.)

(2)  The text of http://www.python.org/dev/ still says 
that deveopment takes place on sourceforge and 
sends people to the sourceforge cvs browser

It also includes a link to (sourceforge) CVS 
instructions, but no mention of subversion.

(3)  The tools link then points to http://www.python.
org/dev/tools.html, which still refers to CVS and CVS 
instructions.

(4)  The developer FAQ (http://www.python.org/dev/
devfaq.html) contains sections 1.2 and 1.4 for 
subversion (combine them?) and 1.3 for CVS -- 
section 1.3 seems to imply that the CVS tree is still 
active.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 09:52

Message:
Logged In: YES 
user_id=1188172

www.python.org/patches says:

We appreciate it if you send patches relative to the
`current svn tree
System Message: WARNING/2 (./index.ht, line 33); backlink
Inline interpreted text or phrase reference start-string
without end-string.

`_.
These are our latest sources. Even a patch relative to the
latest alpha or beta release may be way out of date.


--

Comment By: Brett Cannon (bcannon)
Date: 2005-11-10 22:49

Message:
Logged In: YES 
user_id=357491

Everything but tools.html has been fixed.  That doc really
just needs to be replaced (see python-dev and the thread on
the dev FAQ update for any discussion on the topic) and so
fixing it is not on my list of things to do.  =)

I will leave this bug open, though, until the doc is deleted.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-10 06:48

Message:
Logged In: YES 
user_id=33168

Brett, did you finish updating all these docs?  Is this bug
dead now?

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 00:19

Message:
Logged In: YES 
user_id=21627

I fixed the first two. The latter will be modified later
this year, or next year.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1353793 ] Error in documentation for os.walk

[SourceForge.net]

Bugs item #1353793, was opened at 2005-11-11 10:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Geisler (mgeisler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in documentation for os.walk

Initial Comment:
There's a mistake in the example given for os.walk on
this page:

  http://docs.python.org/lib/os-file-dir.html

The line with sum should read

  print sum([getsize(join(root, name)) for name in files]),

with square brackets.  Otherwise, thanks for the
excellent documentation!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1353793 ] Error in documentation for os.walk

[SourceForge.net]

Bugs item #1353793, was opened at 2005-11-11 04:28
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Martin Geisler (mgeisler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in documentation for os.walk

Initial Comment:
There's a mistake in the example given for os.walk on
this page:

  http://docs.python.org/lib/os-file-dir.html

The line with sum should read

  print sum([getsize(join(root, name)) for name in files]),

with square brackets.  Otherwise, thanks for the
excellent documentation!

--

>Comment By: Tim Peters (tim_one)
Date: 2005-11-11 09:50

Message:
Logged In: YES 
user_id=31435

Your URL is for the Python 2.4.2 docs, where the example 
works fine as given.  If you're using an earlier version of 
Python, the example will not work as given (it relies on 
generator expressions, which were introduced in 2.4).

For example, if you're using Python 2.3.5, you should look at 
the docs for 2.3 instead:

http://www.python.org/doc/2.3.5/lib/os-file-dir.html

Note that square brackets _are_ in that example, because 
Python 2.3.5 required them.  Current Pythons (2.4+) do not, 
so I'm closing this as Not-A-Bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding

[SourceForge.net]

Bugs item #1163244, was opened at 2005-03-14 15:20
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&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 2.4
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Tim N. van der Leeuw (tnleeuw)
>Assigned to: Mark Hammond (mhammond)
Summary: Syntax error on large file with MBCS encoding

Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.

This is a regression from 2.3.5

(With Python2.4, the interpreter crashes. That is fixed
now.)

Removing the mbcs encoding line from the top of the
file, compilation succeeds.

File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).


--

>Comment By: Tim Peters (tim_one)
Date: 2005-11-11 09:56

Message:
Logged In: YES 
user_id=31435

[Mark]
> I can confirm that I can no longer reproduce it
> with the svn release24-maint branch

Did you know 2.4.2 final was released?  That happened 
September 28.  So if someone has this problem, ask them to 
try the released 2.4.2 (no need to muck with release24-
maint).

Leaving this closed, but assigned to Mark just so he'll get 
this note.

--

Comment By: Mark Hammond (mhammond)
Date: 2005-11-11 00:20

Message:
Logged In: YES 
user_id=14198

Thanks Tim!  I can confirm that I can no longer reproduce it
with the svn release24-maint branch - so I'm going out on a
limb and closing it.  I haven't tested Linux, so it would be
great of some others could also confirm it fixed (or reopen
it if not)

--

Comment By: Tim Peters (tim_one)
Date: 2005-11-10 22:31

Message:
Logged In: YES 
user_id=31435

Is this still an issue in 2.4.2?  I downloaded the zip file, and 
didn't have any problem importing the .py file on Windows 
using 2.4.2.  A number of problems with encoding directives 
were fixed in 2.4.2, so I doubt that's an accident ;-)

--

Comment By: James Kew (jkew)
Date: 2005-08-04 13:10

Message:
Logged In: YES 
user_id=598066

http://sourceforge.net/tracker/?
func=detail&aid=1166627&group_id=78018&atid=551954

--

Comment By: Christos Georgiou (tzot)
Date: 2005-08-04 03:50

Message:
Logged In: YES 
user_id=539787

Are you sure about the bug number? pywin32 seems not to have
such a bug.

--

Comment By: James Kew (jkew)
Date: 2005-08-04 02:56

Message:
Logged In: YES 
user_id=598066

Is pywin32 bug 1166627 relevant/related?

--

Comment By: Simon Dahlbacka (sdahlbac)
Date: 2005-07-21 06:38

Message:
Logged In: YES 
user_id=750513

For what it's worth:

I have two files (that I unfortunately cannot attach) which
works fine on 2.3 that now on 2.4.1 produces spurious syntax
errors when they have

# -*- coding: ascii -*-

if I change that to something that does not match the coding
regex I do not get any syntax error

(winxp)

--

Comment By: Niki Spahiev (nikis)
Date: 2005-06-02 12:11

Message:
Logged In: YES 
user_id=27708

i have reproductable test case with encoding cp1251
file is 1594 bytes long, how to attach it?

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-14 19:40

Message:
Logged In: YES 
user_id=89016

Importing foo2.py on Linux (with the current CVS HEAD
version of Python) gives me a segmentation fault with the
following stacktrace:
0x080606cc in instance_repr (inst=0xb7c158bc) at
Objects/classobject.c:880
880 classname = inst->in_class->cl_name;
(gdb) bt
#0  0x080606cc in instance_repr (inst=0xb7c158bc) at
Objects/classobject.c:880
#1  0x08082235 in PyObject_Repr (v=0xb7c158bc) at
Objects/object.c:308
#2  0x080f3ccd in err_input (err=0xbfffe000) at
Python/pythonrun.c:1478
#3  0x080f3956 in PyParser_SimpleParseFileFlags
(fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257,
flags=0)
at Python/pythonrun.c:1348
#4  0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0,
filename=0xbfffe530 "foo2.py", start=257)
at Python/pythonrun.c:1355
#5  0x080e6fef in parse_source_module (pathname=0xbfffe530
"foo2.py", fp=0x818d6e0) at Python/import.c:761
#6  0x080e72db in 

[ python-Bugs-1354052 ] logging: Default handlers broken

[SourceForge.net]

Bugs item #1354052, was opened at 2005-11-11 10:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan S. Joseph (jsjoseph)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging: Default handlers broken

Initial Comment:
Hi,

There is a strange behaviour in logging. When a new
logger is created, its doesn't have any handlers...
until the root logger is invoked, at which point the
new logger uses the same handler as the root handler. 

See the following code snippet as an illustration of
the bug:

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import *
>>> z = getLogger("z")
>>> z.warning("The Larch.")
No handlers could be found for logger "z"
>>> warning("Bicycle Repair Man!")
WARNING:root:Bicycle Repair Man!
>>> z.warning("The Larch.")
WARNING:z:The Larch.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule

[SourceForge.net]

Bugs item #1256669, was opened at 2005-08-11 12:49
Message generated for change (Comment added) made by bheld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Held (bheld)
Assigned to: Nobody/Anonymous (nobody)
Summary: Significant memory leak with PyImport_ReloadModule

Initial Comment:
Having recently upgraded to Python 2.4, I am having a 
large memory 
leak with the following code built with VC++ 6.0: 


PyObject *pName, *pModule; 


Py_Initialize(); 
pName = PyString_FromString(argv[1]); 


pModule = PyImport_Import(pName); 
Py_DECREF(pName); 


PyObject* pModule2 = 
PyImport_ReloadModule(pModule)­; 
Py_DECREF(pModule2); 
Py_DECREF(pModule); 
Py_Finalize(); 
return 0; 


I get leaks of over 500 kb.  I have another program which 
is much more 
complex, in which every call to PyImport_ReloadModule 
is leaking 200+ 
kb, even though I am calling Py_DECREF correctly.


--

>Comment By: Ben Held (bheld)
Date: 2005-11-11 16:13

Message:
Logged In: YES 
user_id=1327580

Turns out this is not a Python issue, but a SWIG issue.  It 
only leaks for modules that were created with SWIG.  Please 
close this item


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-20 06:02

Message:
Logged In: YES 
user_id=33168

I just tested with Python 2.4.2 on Linux with valgrind.  It
doesn't report any leaks.  So this could be specific to
Python 2.3.5, Windows, VC++ 6.0 or some other variation.  

Can you provide more info?  For example, what module are you
passing on the command line?  Can you provide that code? 
What objects specifically do you think are leaking?  Where
were they allocated?

--

Comment By: Ben Held (bheld)
Date: 2005-09-14 18:09

Message:
Logged In: YES 
user_id=1327580

This behavior is evident with Python 2.3.5 built on Windows 
with VC++ 6.0.

--

Comment By: Collin Winter (collinwinter)
Date: 2005-09-14 17:53

Message:
Logged In: YES 
user_id=1344176

I've been unable to verify this on Linux. I've tested python
versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5
on Debian 3.1 under kernel 2.6.8. I used the sample program
provided by Ben, modified with an infinite loop over the
PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for
1 second after every 25 iterations. I tested reloading the
modules distutils, os.path, distutils.command.sdist for 300+
iterations each under each python version. No memory leak
was observed.

--

Comment By: Ben Held (bheld)
Date: 2005-08-16 13:56

Message:
Logged In: YES 
user_id=1327580

Boundschecker shows the leak and I have verified this by 
watching the process memory increase via the task manager.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-08-13 13:34

Message:
Logged In: YES 
user_id=21627

How do you know there is a memory leak?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex

[SourceForge.net]

Feature Requests item #1351692, was opened at 2005-11-08 13:29
Message generated for change (Comment added) made by markhirota
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&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: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hirota (markhirota)
Assigned to: Nobody/Anonymous (nobody)
Summary: Switch to make pprint.pprint display ints and longs in hex

Initial Comment:
It would be nice to have some sort of switch or hook to 
allow 'pretty-printing' of integers and long integers in 
hexidecimal. So, for example:

>>> import pprint
>>> pprint.pprint(range(10)) # instead of this:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> pprint.hexint = True
>>> pprint.pprint(range(10)) # you would get this:
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]
>>> pprint.pprint(range(0x1,0x10010)) # 
and this:
[0x1L,
 0x10001L,
 0x10002L,
 0x10003L,
 0x10004L,
 0x10005L,
 0x10006L,
 0x10007L,
 0x10008L,
 0x10009L,
 0x1000AL,
 0x1000BL,
 0x1000CL,
 0x1000DL,
 0x1000EL,
 0x1000FL]
>>>

Thanks,
--MH

--

>Comment By: Mark Hirota (markhirota)
Date: 2005-11-11 09:47

Message:
Logged In: YES 
user_id=1375527

Is this bypassing considered a limitation or a bug?  I am, 
however, able to workaround the issue by setting the 
width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that 
instead of:

>>> mpp.pprint(range(10))
[0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9]

I get instead:

>>> mpp.pprint(range(10))
[0x0,
 0x1,
 0x2,
 0x3,
 0x4,
 0x5,
 0x6,
 0x7,
 0x8,
 0x9]

...which is OK for my uses.  Thanks!

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-10 14:56

Message:
Logged In: YES 
user_id=89016

In theory this should be possible by subclassing
pprint.PrettyPrinter and overwritting the format method:

import pprint

class MyPrettyPrinter(pprint.PrettyPrinter):
  def format(self, object, context, maxlevels, level):
if isinstance(object, int):
  return hex(object), True, False
else:
  return pprint.PrettyPrinter.format(self, object,
context, maxlevels, level)

mpp = MyPrettyPrinter()
mpp.pprint(range(50))

This doesn't work reliable though: When the string is short
enough, format() seems to be bypassed and repr() is called
directly.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 13:45

Message:
Logged In: YES 
user_id=1188172

Moving to Feature Requests.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1354265 ] Interactive help fails with Windows Installer

[SourceForge.net]

Bugs item #1354265, was opened at 2005-11-11 13:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interactive help fails with Windows Installer

Initial Comment:
help> SPECIALMETHODS

Sorry, topic and keyword documentation is not available
because the Python
HTML documentation files could not be found.  If you
have installed them,
please set the environment variable PYTHONDOCS to
indicate their location.

help>
The problem appears to be that the MS Help .chm is used
and no HTML docs are provided.

Colin W.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule

[SourceForge.net]

Bugs item #1256669, was opened at 2005-08-11 14:49
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&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: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ben Held (bheld)
Assigned to: Nobody/Anonymous (nobody)
Summary: Significant memory leak with PyImport_ReloadModule

Initial Comment:
Having recently upgraded to Python 2.4, I am having a 
large memory 
leak with the following code built with VC++ 6.0: 


PyObject *pName, *pModule; 


Py_Initialize(); 
pName = PyString_FromString(argv[1]); 


pModule = PyImport_Import(pName); 
Py_DECREF(pName); 


PyObject* pModule2 = 
PyImport_ReloadModule(pModule)­; 
Py_DECREF(pModule2); 
Py_DECREF(pModule); 
Py_Finalize(); 
return 0; 


I get leaks of over 500 kb.  I have another program which 
is much more 
complex, in which every call to PyImport_ReloadModule 
is leaking 200+ 
kb, even though I am calling Py_DECREF correctly.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 20:46

Message:
Logged In: YES 
user_id=1188172

Closing as requested.

--

Comment By: Ben Held (bheld)
Date: 2005-11-11 17:13

Message:
Logged In: YES 
user_id=1327580

Turns out this is not a Python issue, but a SWIG issue.  It 
only leaks for modules that were created with SWIG.  Please 
close this item


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-20 08:02

Message:
Logged In: YES 
user_id=33168

I just tested with Python 2.4.2 on Linux with valgrind.  It
doesn't report any leaks.  So this could be specific to
Python 2.3.5, Windows, VC++ 6.0 or some other variation.  

Can you provide more info?  For example, what module are you
passing on the command line?  Can you provide that code? 
What objects specifically do you think are leaking?  Where
were they allocated?

--

Comment By: Ben Held (bheld)
Date: 2005-09-14 20:09

Message:
Logged In: YES 
user_id=1327580

This behavior is evident with Python 2.3.5 built on Windows 
with VC++ 6.0.

--

Comment By: Collin Winter (collinwinter)
Date: 2005-09-14 19:53

Message:
Logged In: YES 
user_id=1344176

I've been unable to verify this on Linux. I've tested python
versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5
on Debian 3.1 under kernel 2.6.8. I used the sample program
provided by Ben, modified with an infinite loop over the
PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for
1 second after every 25 iterations. I tested reloading the
modules distutils, os.path, distutils.command.sdist for 300+
iterations each under each python version. No memory leak
was observed.

--

Comment By: Ben Held (bheld)
Date: 2005-08-16 15:56

Message:
Logged In: YES 
user_id=1327580

Boundschecker shows the leak and I have verified this by 
watching the process memory increase via the task manager.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-08-13 15:34

Message:
Logged In: YES 
user_id=21627

How do you know there is a memory leak?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__

[SourceForge.net]

Bugs item #1328278, was opened at 2005-10-17 03:22
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&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: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Josh Marshall (jpmarshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getslice__ taking priority over __getitem__

Initial Comment:
When creating a class that uses __getitem__ to implement slicing, if 
__getattr__ is also implemented, slicing will fail. This is due to the 
(deprecated) __getslice__ method being called before __getitem__.

The attached file demonstrates this. If __getitem__ is implemented 
on its own, all is rosy. When we add __getattr__ and do not raise an 
AttributeError when __getslice__ is searched for, the slicing fails. If 
we raise this AttributeError, __getitem__ is called next.

The only other reference I could find to this bug is on the jython 
mailing list, from 2003:
http://sourceforge.net/mailarchive/forum.php?
thread_id=2350972&forum_id=5586

My question is; why is __getslice__ called before __getitem__? I 
assumed that because it is deprecated, it would be the last resort for 
a slicing.

Is this planned to be fixed, or is there existing behaviour that is 
reliant on it?
 

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 20:50

Message:
Logged In: YES 
user_id=1188172

You're correct. __getslice__ is supported for backwards
compatibility, and its semantics cannot change (before 3.0,
that is).

--

Comment By: Thomas Lee (krumms)
Date: 2005-11-10 15:48

Message:
Logged In: YES 
user_id=315535

This seems to be the documented, expected behavior:

http://www.python.org/doc/2.4.2/ref/sequence-methods.html

As to _why_ __getslice__ is called before __getitem__, I'm
not sure - but it's right there in the docs.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1350498 ] CVS migration not in www.python.org docs

[SourceForge.net]

Bugs item #1350498, was opened at 2005-11-07 08:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&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
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Brett Cannon (bcannon)
Summary: CVS migration not in www.python.org docs

Initial Comment:
The development head has recently moved from 
CVS on sourceforge to subversion on python.org.

The www.python.org documentation still sends 
people to the sourceforge cvs via

(1)  The left hand navigation link (main page) under 
Documenation section, python project, cvs.  (The 
similar link on http://www.python.org/dev/ has been 
updated.)

(2)  The text of http://www.python.org/dev/ still says 
that deveopment takes place on sourceforge and 
sends people to the sourceforge cvs browser

It also includes a link to (sourceforge) CVS 
instructions, but no mention of subversion.

(3)  The tools link then points to http://www.python.
org/dev/tools.html, which still refers to CVS and CVS 
instructions.

(4)  The developer FAQ (http://www.python.org/dev/
devfaq.html) contains sections 1.2 and 1.4 for 
subversion (combine them?) and 1.3 for CVS -- 
section 1.3 seems to imply that the CVS tree is still 
active.


--

>Comment By: Brett Cannon (bcannon)
Date: 2005-11-11 12:24

Message:
Logged In: YES 
user_id=357491

Fixed.  Thanks, Reinhold.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-11 00:52

Message:
Logged In: YES 
user_id=1188172

www.python.org/patches says:

We appreciate it if you send patches relative to the
`current svn tree
System Message: WARNING/2 (./index.ht, line 33); backlink
Inline interpreted text or phrase reference start-string
without end-string.

`_.
These are our latest sources. Even a patch relative to the
latest alpha or beta release may be way out of date.


--

Comment By: Brett Cannon (bcannon)
Date: 2005-11-10 13:49

Message:
Logged In: YES 
user_id=357491

Everything but tools.html has been fixed.  That doc really
just needs to be replaced (see python-dev and the thread on
the dev FAQ update for any discussion on the topic) and so
fixing it is not on my list of things to do.  =)

I will leave this bug open, though, until the doc is deleted.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-09 21:48

Message:
Logged In: YES 
user_id=33168

Brett, did you finish updating all these docs?  Is this bug
dead now?

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-11-07 15:19

Message:
Logged In: YES 
user_id=21627

I fixed the first two. The latter will be modified later
this year, or next year.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1353793 ] Error in documentation for os.walk

[SourceForge.net]

Bugs item #1353793, was opened at 2005-11-11 10:28
Message generated for change (Comment added) made by mgeisler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&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: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Martin Geisler (mgeisler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in documentation for os.walk

Initial Comment:
There's a mistake in the example given for os.walk on
this page:

  http://docs.python.org/lib/os-file-dir.html

The line with sum should read

  print sum([getsize(join(root, name)) for name in files]),

with square brackets.  Otherwise, thanks for the
excellent documentation!

--

>Comment By: Martin Geisler (mgeisler)
Date: 2005-11-12 00:41

Message:
Logged In: YES 
user_id=1264592

Ups, I'm sorry for the noise then...

--

Comment By: Tim Peters (tim_one)
Date: 2005-11-11 15:50

Message:
Logged In: YES 
user_id=31435

Your URL is for the Python 2.4.2 docs, where the example 
works fine as given.  If you're using an earlier version of 
Python, the example will not work as given (it relies on 
generator expressions, which were introduced in 2.4).

For example, if you're using Python 2.3.5, you should look at 
the docs for 2.3 instead:

http://www.python.org/doc/2.3.5/lib/os-file-dir.html

Note that square brackets _are_ in that example, because 
Python 2.3.5 required them.  Current Pythons (2.4+) do not, 
so I'm closing this as Not-A-Bug.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1354052 ] logging: Default handlers broken

[SourceForge.net]

Bugs item #1354052, was opened at 2005-11-11 07:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan S. Joseph (jsjoseph)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging: Default handlers broken

Initial Comment:
Hi,

There is a strange behaviour in logging. When a new
logger is created, its doesn't have any handlers...
until the root logger is invoked, at which point the
new logger uses the same handler as the root handler. 

See the following code snippet as an illustration of
the bug:

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import *
>>> z = getLogger("z")
>>> z.warning("The Larch.")
No handlers could be found for logger "z"
>>> warning("Bicycle Repair Man!")
WARNING:root:Bicycle Repair Man!
>>> z.warning("The Larch.")
WARNING:z:The Larch.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-11 17:51

Message:
Logged In: YES 
user_id=33168

This may have been fixed recently.  Vinay?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1354052 ] logging: Default handlers broken

[SourceForge.net]

Bugs item #1354052, was opened at 2005-11-11 15:03
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&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: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jonathan S. Joseph (jsjoseph)
Assigned to: Vinay Sajip (vsajip)
Summary: logging: Default handlers broken

Initial Comment:
Hi,

There is a strange behaviour in logging. When a new
logger is created, its doesn't have any handlers...
until the root logger is invoked, at which point the
new logger uses the same handler as the root handler. 

See the following code snippet as an illustration of
the bug:

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import *
>>> z = getLogger("z")
>>> z.warning("The Larch.")
No handlers could be found for logger "z"
>>> warning("Bicycle Repair Man!")
WARNING:root:Bicycle Repair Man!
>>> z.warning("The Larch.")
WARNING:z:The Larch.

--

>Comment By: Vinay Sajip (vsajip)
Date: 2005-11-12 02:51

Message:
Logged In: YES 
user_id=308438

This is not a bug, this is by design. See the documentation for 
basicConfig() in

http://docs.python.org/lib/module-logging.html

where you will see that the module-level convenience functions 
(debug(), info(), warning(), etc.) call basicConfig() automatically 
if the root logger has no handlers.

The idea is, if you are using the convenience functions, you 
will be using logging in a simple way - hence, basicConfig() is 
called for you. If you had used the root logger directly, e.g. 
after

from logging import *

by using

getLogger().warning("Bicycle Repair Man!")

rather than

warning("Bicycle Repair Man!")

then no handlers would have been added. You would not have 
received the "No handlers could be found", as that is a one-off 
message. In the latest revisions, if you set raiseExceptions to 
0 (typically for production, not development) then that 
message is suppressed completely.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-12 01:51

Message:
Logged In: YES 
user_id=33168

This may have been fixed recently.  Vinay?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com