[ python-Feature Requests-1379573 ] python executable optionally should search script on PATH

[SourceForge.net]

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by cconrad
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

--

>Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

--

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

--

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

--

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

[ python-Bugs-1393109 ] cannot build SVN trunk on old systems

[SourceForge.net]

Bugs item #1393109, was opened at 2005-12-29 21:25
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&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: Pending
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot build SVN trunk on old systems

Initial Comment:
Parser/asdl_c.py uses "/usr/bin/env python" to
find a proper python, but the script don't work
on old Pythons (at least it fails on 2.1 and
older).

iirc, various solutions to this were discussed on
python-dev, but nobody seems to have done anything
about it.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-11 23:47

Message:
Logged In: YES 
user_id=21627

Is this still a problem? Parser/asdl_c.py should not
normally be invoked, unless you edit the grammar

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-01-02 05:31

Message:
Logged In: YES 
user_id=33168

One issue I see in asdl.py is that new-style classes are
used.  I don't know if they are really necessary.  You could
try adding something like this to the top of asdl.py and see
if that fixes things:

try:
  object
except NameError:
  class object: pass

Or maybe we just shouldn't make them new-style if that does
fix things.  I don't have an old version of python around.

--

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

[ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__

[SourceForge.net]

Bugs item #1367183, was opened at 2005-11-26 22:42
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&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: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

 if not isinstance(doc, types.StringTypes):
 return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
 return None
doc = str(doc)



--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:21

Message:
Logged In: YES 
user_id=1188172

I don't know. Neal, do you have an opinion about property
docstrings?

--

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 12:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...def _get(self):
...return 'the docstring'
...__doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__

>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

--

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

[ python-Bugs-969718 ] BASECFLAGS are not passed to module build line

[SourceForge.net]

Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&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
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Beardsley (vaxhacker)
>Assigned to: Martin v. Löwis (loewis)
Summary: BASECFLAGS are not passed to module build line

Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build").  It seems that
only the value of OPT is passed along.

This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).

I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.


--

Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19

Message:
Logged In: YES 
user_id=1426882

This is still a bug in Python 2.4.2.

--

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

[ python-Bugs-969718 ] BASECFLAGS are not passed to module build line

[SourceForge.net]

Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&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
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Beardsley (vaxhacker)
Assigned to: Martin v. Löwis (loewis)
Summary: BASECFLAGS are not passed to module build line

Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build").  It seems that
only the value of OPT is passed along.

This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).

I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.


--

Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19

Message:
Logged In: YES 
user_id=1426882

This is still a bug in Python 2.4.2.

--

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

[ python-Bugs-1413790 ] zipfile: inserting some filenames produces corrupt .zips

[SourceForge.net]

Bugs item #1413790, was opened at 2006-01-24 16:57
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Grant Olson (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile: inserting some filenames produces corrupt .zips

Initial Comment:
Running something like the following produces a corrupt
.zip file.  The builtin XP zip folder view won't show
any documents and attempting to extract via "right
click -> Extract files..." will set off an untrusted
file alert:

import zipfile
z = zipfile.ZipFile("c:\\foo.zip","w")
z.write("c:\\autoexec.bat", "\\autoexec.bat")
z.close()

zipfile should either throw an error when adding these
files or attempt to normalize the path.  I would prefer
that zipfile make the assumption that any files
starting with absolute or relative pathnames
("\\foo\\bar.txt" or ".\\foo\\bar.txt") should join in
at the root of the zipfile ("foo\\bar.txt" in this case).

Patch to accomplish the latter is attached.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:13

Message:
Logged In: YES 
user_id=1188172

Thanks for the bug report, fixed in rev. 42508.

--

Comment By: Grant Olson (logistix)
Date: 2006-01-25 21:52

Message:
Logged In: YES 
user_id=699438

Just wanted to note that the documentation of the .zip
format from pkzip explicitly states that a drive letter or
leading slash is not allowed.  The pertinent text:

file name: (Variable)

  The name of the file, with optional relative path.
  The path stored should not contain a drive or
  device letter, or a leading slash.  All slashes
  should be forward slashes '/' as opposed to
  backwards slashes '\' for compatibility with Amiga
  and UNIX file systems etc.  If input came from
standard
  input, there is no file name field.  If encrypting
  the central directory and general purpose bit flag
13 is set 
  indicating masking, the file name stored in the
Local Header 
  will not be the actual file name.  A masking value
consisting 
  of a unique hexadecimal value will be stored. 
This value will 
  be sequentially incremented for each file in the
archive. See
  the section on the Strong Encryption Specification
for details 
  on retrieving the encrypted file name. 


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1413790&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-1379573 ] python executable optionally should search script on PATH

[SourceForge.net]

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:14

Message:
Logged In: YES 
user_id=1188172

Do you mean that the registry setting is ok, but the
parameters are not passed correctly?

--

Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

--

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

--

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

--

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

[ python-Bugs-729236 ] building readline module fails on Irix 6.5

[SourceForge.net]

Bugs item #729236, was opened at 2003-04-29 01:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5

Initial Comment:
I am trying to build  Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30

I can't get the readline module to build. I get the
following error:
cc  -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include 
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
  The "return" expression type differs from the
function return type.

return completion_matches(text, *on_completion);
   ^

cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
  The variable "m" is set but never used.

PyObject *m;
  ^

1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:15

Message:
Logged In: YES 
user_id=1188172

Is this still the case with Python 2.4?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 01:49

Message:
Logged In: YES 
user_id=33168

Is HAVE_RL_COMPLETION_MATCHES defined?  If so is
rl_completion_matches() defined to return char ** in
readline.h?  If HAVE_* is not defined, where is
completion_matches() defined and what does it return?

--

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 20:02

Message:
Logged In: YES 
user_id=150999

I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?

** readline.c  2003-05-09 13:45:38.0 -0700
--- readline.c~ 2003-03-01 07:19:41.0 -0800
***
*** 577,589 
  /* A more flexible constructor that saves the "begidx" and
"endidx"
   * before calling the normal completer */

! static char ** flex_complete(char *text, int start, int end)
  {
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
!   return (char **)completion_matches(text,
*on_completion);
  }


--- 577,590 
  /* A more flexible constructor that saves the "begidx" and
"endidx"
   * before calling the normal completer */

! static char **
! flex_complete(char *text, int start, int end)
  {
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
!   return completion_matches(text, *on_completion);
  }











--

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 19:44

Message:
Logged In: YES 
user_id=150999

My readline version is 4.3

--

Comment By: Martin v. Löwis (loewis)
Date: 2003-04-29 13:44

Message:
Logged In: YES 
user_id=21627

What is your readline version?

--

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

[ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run after test_openpty

[SourceForge.net]

Bugs item #713169, was opened at 2003-04-01 09:35
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&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: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

--

Comment By: Michael Hoffman (hoffmanm)
Date: 2005-01-25 17:29

Message:
Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.

--

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 10:30

Message:
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i


--

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 18:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 18:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

--

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 12:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

--

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

[ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__

[SourceForge.net]

Bugs item #1367183, was opened at 2005-11-26 22:42
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&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: Drew Perttula (drewp)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: inspect.getdoc fails on objs that use property for __doc__

Initial Comment:
inspect.getdoc has these lines:

 if not isinstance(doc, types.StringTypes):
 return None

which interfere with the case where __doc__ is some
other thing that has a good __str__. I wanted to make a
lazy __doc__ that did an expensive lookup of some
external documentation only when it was str()'d, but
since doc displayers often (correctly) use
inspect.getdoc, they were getting None.

I think the intention of the test in getdoc() is to
avoid trying string operations on a __doc__ that is
None. I think that a more lenient version would allow
me to do my fancy docstrings but still solve the
'__doc__ is None' problem. Please consider the
following patch:

if doc is None:
 return None
doc = str(doc)



--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 09:21

Message:
Logged In: YES 
user_id=1188172

I don't know. Neal, do you have an opinion about property
docstrings?

--

Comment By: Collin Winter (collinwinter)
Date: 2006-02-01 12:35

Message:
Logged In: YES 
user_id=1344176

It's not a good idea to use properties for __doc__:

"""
>>> class Foo(object):
...def _get(self):
...return 'the docstring'
...__doc__ = property(_get)
...
>>> print Foo().__doc__
the docstring
>>> print Foo.__doc__

>>>
"""

In this light, I don't view inspect.getdoc's lack of support
for __doc__-as-property as a bug.

--

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

[ python-Bugs-818490 ] socketmodule.c compile error using SunPro cc

[SourceForge.net]

Bugs item #818490, was opened at 2003-10-06 10:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818490&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.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Rick Ratzel (rlratzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c compile error using SunPro cc

Initial Comment:

   If the _socket module is to be included in
libpython.a rather than built as a shared lib (by
specifying it in Modules/Setup.local under a *static*
line), compile errors result on SunOS 5.7 using the Sun
WorkShop 6 compiler.  Undefined symbol "AF_INET6" on
line 2972 and undefined symbol "INET_ADDRSTRLEN" on
3016 are a few of the errors...please see the attached
output file.

   Note that the configure process completed successfully.

   Here is some additional info:

Python version: 2.3.2
"uname -a" output: SunOS blueberry 5.7
Generic_106541-15 sun4u sparc SUNW,Ultra-60
compiler version: Sun WorkShop 6 update 1 C 5.2 2000/09/11


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:31

Message:
Logged In: YES 
user_id=1188172

Duplicate of #854823.

--

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

[ python-Bugs-854823 ] Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

[SourceForge.net]

Bugs item #854823, was opened at 2003-12-05 17:01
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Falko Sauermann (fsm2761)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

Initial Comment:
Compiling Python-2.3.3c1 on Solaris 2.7 with gcc 2.95.3
gave me two errors:

socketmodule.c:2975: `AF_INET6' undeclared (first use
in this function)

socketmodule.c:3019: `INET_ADDRSTRLEN' undeclared
(first use in this function)

The first problem was already reported for Solaris 2.7
with SunPro cc (see item 814613) but is also true for
Solaris 2.7 with gcc.

The real problem is that AF_INET6 is used when
ENABLE_IPV6 is undefined. I believe this must fail for
any system where IPV6 is not avalilable.

The second problem was already reported for Irix (see
item 818490) but is also true for Solaris 2.7. The
solution for Irix is also valid for Solaris. If I
change socketmodule.c line 204 to:

#if (defined(__sgi) || defined(sun)) &&
!defined(INET_ADDRSTRLEN)

the error is gone.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:46

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:44

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 19:52

Message:
Logged In: YES 
user_id=246063

Okay, here are my results:

Python 2.3.3 and 2.3.4 both give errors about both AF_INET6
and INET_ADDRSTRLEN being undeclared. The line numbers are
different, but everything else is the same. The specific
errors from the 2.3.4 install are:

socketmodule.c:2979: `AF_INET6' undeclared (first use in
this function)
socketmodule.c:3023: `INET_ADDRSTRLEN' undeclared (first use
in this function)


Python 2.4b1 only gives an error about INET_ADDRSTRLEN:

socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use
in this function)


The string INET_ADDRSTRLEN did not appear anywhere in the
files under /usr/include on this system.

In the 2.4b1 tree, if I just #define INET_ADDRSTRLEN to 16,
as hinted by Lib/plat-sunos5/IN.py, then socketmodule.c
compiles with only minor warnings. I don't know the right
way to get this information into the source file though,
sorry. Also, I'm not sure what a good test would be to
determine whether this value is actually correct.

Because a fresh build of both 2.3.4 and 2.4b1 does not
create the _socket module, I believe this bug should not yet
be closed.

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 03:11

Message:
Logged In: YES 
user_id=246063

I built and installed both 2.3.3 and 2.3.4, and I get the
same error that I was before. It actually occurs in the
install phase, when building socketmodule.c. This is on
Solaris 2.7 with gcc 2.95.2.

I've run out of time tonight to finish building 2.4b1, but
I'll do that tomorrow and see what happens.

I'm happy to provide the complete or partial build logs if
that would help.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-19 03:29

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-18 04:37

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-02-26 18:23

Message:
Logged In: YES 
user_id=246063

I think it's worth noting that the preprocessor directive
near line 2975 is #ifndef , whereas all other preprocessor
directives in the file that refer to the IPV6 symbol are
#ifdef . In other words, it looks like just that one
directive is a typo. Changing #ifndef to #ifdef fixes it for me.

--

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

[ python-Bugs-854823 ] Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

[SourceForge.net]

Bugs item #854823, was opened at 2003-12-05 17:01
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Falko Sauermann (fsm2761)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

Initial Comment:
Compiling Python-2.3.3c1 on Solaris 2.7 with gcc 2.95.3
gave me two errors:

socketmodule.c:2975: `AF_INET6' undeclared (first use
in this function)

socketmodule.c:3019: `INET_ADDRSTRLEN' undeclared
(first use in this function)

The first problem was already reported for Solaris 2.7
with SunPro cc (see item 814613) but is also true for
Solaris 2.7 with gcc.

The real problem is that AF_INET6 is used when
ENABLE_IPV6 is undefined. I believe this must fail for
any system where IPV6 is not avalilable.

The second problem was already reported for Irix (see
item 818490) but is also true for Solaris 2.7. The
solution for Irix is also valid for Solaris. If I
change socketmodule.c line 204 to:

#if (defined(__sgi) || defined(sun)) &&
!defined(INET_ADDRSTRLEN)

the error is gone.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:44

Message:
Logged In: YES 
user_id=1188172

Fixed in revisions 42509, 42510.

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 19:52

Message:
Logged In: YES 
user_id=246063

Okay, here are my results:

Python 2.3.3 and 2.3.4 both give errors about both AF_INET6
and INET_ADDRSTRLEN being undeclared. The line numbers are
different, but everything else is the same. The specific
errors from the 2.3.4 install are:

socketmodule.c:2979: `AF_INET6' undeclared (first use in
this function)
socketmodule.c:3023: `INET_ADDRSTRLEN' undeclared (first use
in this function)


Python 2.4b1 only gives an error about INET_ADDRSTRLEN:

socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use
in this function)


The string INET_ADDRSTRLEN did not appear anywhere in the
files under /usr/include on this system.

In the 2.4b1 tree, if I just #define INET_ADDRSTRLEN to 16,
as hinted by Lib/plat-sunos5/IN.py, then socketmodule.c
compiles with only minor warnings. I don't know the right
way to get this information into the source file though,
sorry. Also, I'm not sure what a good test would be to
determine whether this value is actually correct.

Because a fresh build of both 2.3.4 and 2.4b1 does not
create the _socket module, I believe this bug should not yet
be closed.

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-10-20 03:11

Message:
Logged In: YES 
user_id=246063

I built and installed both 2.3.3 and 2.3.4, and I get the
same error that I was before. It actually occurs in the
install phase, when building socketmodule.c. This is on
Solaris 2.7 with gcc 2.95.2.

I've run out of time tonight to finish building 2.4b1, but
I'll do that tomorrow and see what happens.

I'm happy to provide the complete or partial build logs if
that would help.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-19 03:29

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-10-18 04:37

Message:
Logged In: YES 
user_id=33168

Does this problem still exist in 2.3.4 or 2.4b1?  Can this
be closed?

--

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-02-26 18:23

Message:
Logged In: YES 
user_id=246063

I think it's worth noting that the preprocessor directive
near line 2975 is #ifndef , whereas all other preprocessor
directives in the file that refer to the IPV6 symbol are
#ifdef . In other words, it looks like just that one
directive is a typo. Changing #ifndef to #ifdef fixes it for me.

--

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

[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?

[SourceForge.net]

Bugs item #1212703, was opened at 2005-06-01 15:05
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&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: Platform-specific
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?

Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])

Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC


(...)
creating Makefile
aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)   { return
__truncate64(a,b); }
 ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)   { return
__prealloc64(a,b); }
 ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)   { return
__lockf64(a,b,c); }
 ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)  { return
__ftruncate64(a,b); }
 ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
   inline lstat __((const char *, struct stat *));
  ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
  definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.
aCC -c  -DNDEBUG -O  -I. -I./Include  
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline truncate(const char *a, off_t b)   { return
__truncate64(a,b); }
 ^
 
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline prealloc(int a, off_t b)   { return
__prealloc64(a,b); }
 ^
 
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline lockf(int a, int b, off_t c)   { return
__lockf64(a,b,c); }
 ^
 
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
  inline ftruncate(int a, off_t b)  { return
__ftruncate64(a,b); }
 ^
 
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
  type is nonstandard ("int" assumed)
   inline lstat __((const char *, struct stat *));
  ^
 
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
  definition appears wrong for platform (bad
gcc/glibc
config?)."
  #error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
   ^
 
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
 
Stop.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-09-20 08:32

Message:
Logged In: YES 
user_id=29957

As far as I know, the patches contributed by Elemental
Security make current CVS HEAD work fine on ia64 HP/UX.
Please do test them, though - I think Guido put some notes
in the toplevel README about how to get the build to work.


--

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

Message:
Logged In: YES 
user_id=33168

I think there was a fix checked in recently to address some
(hopefully all) of these issues.  Does the current CVS build
on your HPUX box?

--

Comment By: Vincent Jamart (ranma)
Date: 2005-06-29 08:50

Message:
Logged In: YES 
user_id=150220

This is how we managed to solve the problem here, but it's
not a clean solution:

#install script for HP-UX 11.xx
CPPFLAGS="

[ python-Bugs-1002465 ] MemoryError on AIX52

[SourceForge.net]

Bugs item #1002465, was opened at 2004-08-03 10:04
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&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.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Datranet (richardjmason)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError on AIX52

Initial Comment:
I found the orginal problem when trying to send large 
email attachments on AIX 5.2. I tracked the issue down 
to the fact that a string can only grow to a very 
restricted size on AIX 5.2. bin2ascii fails at the pint the 
function tries to join the list togther to form 1 string.

I wrote the following test program to prove the issue:

a = ''
cnt = 0

while cnt < 1024:
 a = a + 'x'
 cnt += 1

c = ''
cnt = 0

while cnt < 1024:
 c = c + a
 cnt += 1

b = ''
cnt2 = 0

while 1:
   b = b + c
   cnt2 += 1
   print cnt2

On AIX 5.2 you get a MemoryError with a cnt2 value of 
42. I can run the test program on all other platforms and 
get a cnt2 value over 150 before stopping to program 
myself.

I have tried the binary python 2.2 from the IBM site and 
building python 2.3.4 myself using the gcc from the IBM 
site. Both fail with a cnt2 value of 42.

Can anyone please advise on how to get AIX 5.2 to 
allow single objects to have more memory allocated.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 07:23

Message:
Logged In: YES 
user_id=33168

richardjmason, are you still having this problem?

--

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:59

Message:
Logged In: YES 
user_id=6656

A way this has happened in the past is calling "malloc(0)",
which is entitled to return NULL and Python then thinks this
is a memory error.  This doesn't seeme especially likely
here, though.  Agree with Martin that you're probably going
to need to use a debugger.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-08-04 20:09

Message:
Logged In: YES 
user_id=21627

You need to use a debugger to find the cause of the problem.
What is the string parameter of the MemoryError? This might
give a clue where precisely it is raised.

--

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

[ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=

[SourceForge.net]

Bugs item #1355842, was opened at 2005-11-13 11:17
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Armin Rigo (arigo)
Summary: Incorrect Decimal-float behavior for += and *=

Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).

Example:

>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented

A blatant violation of "Errors should never pass silently."

Also, a bad error description is produced for the *=
operator:

>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't multiply sequence by non-int


--

>Comment By: Armin Rigo (arigo)
Date: 2006-02-20 10:22

Message:
Logged In: YES 
user_id=4771

Backported as r42511.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-19 00:05

Message:
Logged In: YES 
user_id=1188172

The patch was committed and fixed this, but only in SVN
HEAD, not for 2.4.

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-26 16:31

Message:
Logged In: YES 
user_id=4771

See proposed patch: #1390657

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-22 21:31

Message:
Logged In: YES 
user_id=38388

Hi Facundo,

the problem you are seeing seems to be in the way new-style
classes implement number coercion. 

Apparently some part in the (not so new-style anymore)
coercion logic is masking an exception which then triggers
later during processing. 

The NotImplemented singleton should never make it to the
interactive shell since it is normally only used internally
by the number coercion logic to signal "object method
doesn't handle mixed type operation".


--

Comment By: Facundo Batista (facundobatista)
Date: 2005-12-22 17:10

Message:
Logged In: YES 
user_id=752496

Regarding problem 1:

Nick also detected this behaviour, back in March
(http://mail.python.org/pipermail/python-dev/2005-March/051834.html),
in python-dev discussions about how integrate better the
Decimal behaviour into Python framework.

Even knowing this, Raymond Hettinger and I made a patch
(almost exactly the same), and corrected another behaviour.
Will this issue be resolved somewhen? Raymond said that this
problem is also present in sets.py and datetime objects
(http://mail.python.org/pipermail/python-dev/2005-March/051825.html),
and that should be addressed in a larger context than decimal.

As Neil Schemenauer proposed
(http://mail.python.org/pipermail/python-dev/2005-March/051829.html),
Decimal now returns NotImplemented instead of raise
TypeError, which should be the correct way to deal with
operation capabilities in the numbers.

And look at this:

>>> d
Decimal("1")   # using decimal.py rev. 39328 from svn
>>> d + 1.2
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: unsupported operand type(s) for +: 'Decimal' and
'float'
>>> d += 1.2
>>> d
NotImplemented
>>>

Why this happens? Really don't know, it's beyond my actual
knowledge, I'll keep searching. But I'm not so sure that
this is a Decimal issue.


Regarding problem 2:

I'll fix that.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-22 05:52

Message:
Logged In: YES 
user_id=33168

Facundo, can you look into this?  Are you still working on
Decimal?

--

Comment By: Connelly (connelly)
Date: 2005-12-02 06:17

Message:
Logged In: YES 
user_id=1039782

The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:

>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented

>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't multiply sequence by non-int


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 04:43

Message:
Logged In: YES 
user_id=33168

Hmmm.  __add__ returns NotImplemented which works with
classic classes, but not new-style classes.  I wonder if
NotImplementedError is supposed to be raised for new-style
classes.  

--

You can resp

[ python-Bugs-872175 ] README build instructions for fpectl

[SourceForge.net]

Bugs item #872175, was opened at 2004-01-07 07:15
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&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: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steve Chaplin (stevech)
Assigned to: Nobody/Anonymous (nobody)
Summary: README build instructions for fpectl

Initial Comment:
configure.in supports the option '--with-fpectl'

However, the "Configuration options and variables"
section in the Python-2.3.3/README file mentions many
options, but does not mention --with-fpectl

I think the README should contain a few lines saying
what the default setting is and why you may want to
switch it on or off.


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:24

Message:
Logged In: YES 
user_id=1188172

Added a note in rev. 42512.

--

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

[ python-Bugs-1188231 ] Rebuilding from source on RH9 fails (_tkinter.so missing)

[SourceForge.net]

Bugs item #1188231, was opened at 2005-04-22 20:21
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&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: Pending
Resolution: None
Priority: 5
Submitted By: Marty Heyman (mheyman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rebuilding from source on RH9 fails (_tkinter.so missing)

Initial Comment:
On a Red Hat 9 system, I downloaded the python2.4-2.4.
1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild .
..". It went a long for a good long while with no apparent errors and 
then said:

---

RPM build errors:
   File not found by glob: /var/tmp/python2.4-2.4.
1-root/usr/lib/python2.4/lib-dynload/_tkinter.so*

---
I looked in the directory and there is, in fact, no _tkinter.so file(s) 
there. 

--
Marty Heyman

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:25

Message:
Logged In: YES 
user_id=1188172

This looks like it is not Python's fault.

--

Comment By: green-ghost (green-ghost)
Date: 2005-07-30 17:35

Message:
Logged In: YES 
user_id=1321225

I had a similar problem compiling python from source on a
(nominally) redhat8 system.  For whatever reason, X11
headers were not installed (probably because it's a server I
only use from an ssh console). YMMV

Try:
apt-get install XFree86-devel
or:
rpm -i XFree86-devel-.rpm

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-05-02 23:16

Message:
Logged In: YES 
user_id=21627

Ah, so it seems you are lacking the X11 header files. They
should have been installed as a dependency on the Tk
headers. So this is either a Redhat bug (for not including a
dependency of the -dev packages) or a local misconfiguration
of some kind (e.g. forcefully installing Tk headers without
all prerequisites present).

--

Comment By: Marty Heyman (mheyman)
Date: 2005-04-22 20:42

Message:
Logged In: YES 
user_id=421967

APOLOGIES: ADDITIONAL INFO FOLLOWS 
---Snip from rebuild output follows
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory
In file included from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tk.h:581: parse error before "Bool"
/usr/include/tk.h:583: parse error before "event"
/usr/include/tk.h:584: parse error before "root"
/usr/include/tk.h:585: parse error before "subwindow"
/usr/include/tk.h:586: parse error before "time"
/usr/include/tk.h:586: `time' redeclared as different kind
of symbol
/usr/include/time.h:184: previous declaration of `time'
/usr/include/tk.h:591: parse error before "same_screen"
--- snip ends
many more "parse error lines occurred after this. I doubt
they're interesting .
A bit later, another group of failures begins
--Snip starts
In file included from /usr/include/tk.h:1361,
 from
/usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67:
/usr/include/tkDecls.h:37: parse error before '*' token
/usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC"
/usr/include/tkDecls.h:45: parse error before "Drawable"
/usr/include/tkDecls.h:50: parse error before "Drawable"
/usr/include/tkDecls.h:58: parse error before "XEvent"
--Snip ends
   Again, there are many more similar messages following
those and then:
--Snip starts
/usr/include/tkDecls.h:843: `GC' declared as function
returning a function
... [parse errors]
/usr/include/tkDecls.h:906: `Font' declared as function
returning a function
--Snip ends
There are many such embedded in that group. Then the
messages stop followed by a line that says: "running
build_scripts" ... and things proceed as if all was OK for
hundreds more lines of output before the failure copied into
the original report.

I captured the complete log and can upload it if needed on
request. I'd need to trim it and it doesn't look all that
interesting otherwise but then, what do I know :-)


--

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

[ python-Bugs-1071597 ] configure problem on HP-UX 11.11

[SourceForge.net]

Bugs item #1071597, was opened at 2004-11-23 11:30
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&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: Platform-specific
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure problem on HP-UX 11.11

Initial Comment:
Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ 
 
Using gcc 3.3.3 to build on HP-UX 11.11, the  
configure out of the box is a bit off, resulting in a failed build, due 
to missing thread symbols: 
 
/usr/ccs/bin/ld: Unsatisfied symbols: 
   PyThread_acquire_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_exit_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_allocate_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_free_lock (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_start_new_thread (first referenced in 
libpython2.4.a(threadmodule.o)) (code) 
   PyThread_release_lock (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread_get_thread_ident (first referenced in 
libpython2.4.a(import.o)) (code) 
   PyThread__init_thread (first referenced in 
libpython2.4.a(thread.o)) (code) 
collect2: ld returned 1 exit status 
 
A workaround is to manually edit pyconfig.h, adding  
#define _POSIX_THREADS 
 
(The reason it is not picked up is that unistd.h on HP-UX has this 
comment: 
 
/ 
 * The following defines are specified in the standard, but are not 
yet 
 * implemented: 
 * 
 *_POSIX_THREADS can't be defined until all 
 *   features are implemented 
) 
 
The implementation seems however to be sufficiently complete 
to permit compiling and running Python with _POSIX_THREADS. 
 
While I'm editing pyconfig.h, I also comment out 
_POSIX_C_SOURCE definition, as it will result in lots of 
compilation warnings, of the style: 
 
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I. -I../Python-2.4c1/Include  
-DPy_BUILD_CORE -o 
Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c 
In file included from ../Python-2.4c1/Include/Python.h:8, 
 from ../Python-2.4c1/Objects/frameobject.c:4: 
pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined 
:6:1: warning: this is the location of the 
previous definition 
 
 
 
So, to recapitulate:  After configure, add  
#define _POSIX_THREADS 
and comment out 
#define _POSIX_C_SOURCE 200112L 
 
That will give you a Python working rather well,  
with "make test" producing: 
 
251 tests OK. 
1 test failed: 
test_pty 
38 tests skipped: 
test_aepack test_al test_applesingle test_bsddb 
test_bsddb185 
test_bsddb3 test_cd test_cl test_codecmaps_cn 
test_codecmaps_hk 
test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw 
test_curses 
test_dl test_gdbm test_gl test_imgfile test_largefile 
test_linuxaudiodev test_locale test_macfs test_macostools 
test_nis 
test_normalization test_ossaudiodev test_pep277 test_plistlib 
test_scriptpackages test_socket_ssl test_socketserver 
test_sunaudiodev test_tcl test_timeout test_urllib2net 
test_urllibnet test_winreg test_winsound 
1 skip unexpected on hp-ux11: 
test_tcl 
 
 
 

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:27

Message:
Logged In: YES 
user_id=1188172

cbeatley: your problem should be fixed as the pwd module is
now builtin.

OP: do you still have problems with recent releases?

--

Comment By: Cameron Beatley (cbeatley)
Date: 2005-06-15 22:18

Message:
Logged In: YES 
user_id=991535

I have the same problems. When I edit the pyconfig.h file as 
described and run Make again, I get the following

Traceback (most recent call last):
  File "./setup.py", line 1184, in ?
main()
  File "./setup.py", line 1178, in main
scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
  File "/CVS/apps/Python-2.4.1/Lib/distutils/core.py", line 
123, in setup
dist.parse_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 339, 
in parse_config_files
filenames = self.find_config_files()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/dist.py", line 302, 
in find_config_files
check_environ()
  File "/CVS/apps/Python-2.4.1/Lib/distutils/util.py", line 155, 
in check_environ
import pwd
ImportError: No module named pwd
*** Error exit code 1


any idea what THIS is?

[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility

[SourceForge.net]

Bugs item #1086854, was opened at 2004-12-17 05:07
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Friesner (jfriesne)
>Assigned to: Martin v. Löwis (loewis)
Summary: "slots" member variable in object.h confuses Qt moc utility

Initial Comment:
This isn't really a Python bug per se, but it's easy to fix so I'm 
filing a bug report anyway.  The problem is with the line  
 
PyObject *name, *slots; 
 
in the definition of struct _heaptypeobject at line 343 of 
Include/object.h.  I'm embedding Python into my app that uses 
the TrollTech Qt GUI, and Qt has a preprocessor program 
named "moc" that looks for certain non-standard keywords.  
 
One of these keywords is the word "slots"... so having a 
member variable named "slots" in Include/object.h confuses 
moc and causes my app to have a build error.  I was able to 
fix the problem by renaming the "slots" member variable to 
"xslots" in the Python source, but it would be nicer if it was 
renamed in the official Python distribution so that the problem 
doesn't come up for the next guy. 
 

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:29

Message:
Logged In: YES 
user_id=1188172

Assigning you again, Martin: should I change the names for 2.5?

--

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

Message:
Logged In: YES 
user_id=21627

I would assume that the changes are necessary *only* in
header files, which means that only heaptype is to be changed.

I don't know what happened to the old principle of
protecting struct members against name collisions; I think
if they are to be renamed, their names should be ht_type,
ht_name, ht_slots. (I never understood the rationale for
this convention until this report: there always might be a
collision with a macro name).

Unfortunately, such a change is not so easy as it may sound:
it may break existing applications. Still, I think it should
be done, but only for 2.5.

Unassigning myself.

--

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-30 17:38

Message:
Logged In: YES 
user_id=383828

On second thought, I believe mwh is right; most of those
changes are unnecessary.  (I made the changes a long time
ago, so when I grepped for them the other day the memory for
their motivation wasn't fresh).  The Python .c files aren't
fed to moc, so references to 'signals' and 'slots' in the .c
files should compile okay.  It's just the references to
those identifiers in the Python .h files that cause a
problem, if the .h files are #included in a Qt-using C++
program, after #including a Qt header.  So I think probably
just the original three changes are sufficient.

--

Comment By: Michael Hudson (mwh)
Date: 2005-09-30 10:44

Message:
Logged In: YES 
user_id=6656

I'm not particularly convinced that this is a great idea.  Python uses 'new' 
and 'class' as C identifiers which mean you can't compile it as C++ -- but 
Python isn't written in C++, so this is fine.  Similarly, Python isn't designed 
to be fed to moc -- so why feed it to moc?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:50

Message:
Logged In: YES 
user_id=1188172

Ah, okay. However, I can't decide whether this will be done,
assigning to Martin for this case.

--

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-29 22:48

Message:
Logged In: YES 
user_id=383828

Unfortunately, yes,  When compiling with Qt, the words "signals" 
and "slots" become essentially reserved keywords, and any use of 
them as variable names causes a compile error. 

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-29 22:37

Message:
Logged In: YES 
user_id=1188172

Okay. Most of your replacements are function parameters or
function local variables, do they have to be replaced too?

--

Comment By: Jeremy Friesner (jfriesne)
Date: 2005-09-28 18:59

Message:
Logged In: YES 
user_id=383828

Here is a file containing grep output showing all the lines
where I changed 'slots' to 'xslots' in my codebase:

http://www.lcscanada.com/jaf/xslots.zip

--

Comme

[ python-Bugs-1101233 ] test_fcntl fails on netbsd2

[SourceForge.net]

Bugs item #1101233, was opened at 2005-01-12 22:30
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101233&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Howard (mikeh-id)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_fcntl fails on netbsd2

Initial Comment:
edit line 23 of test_fcntl.py to add 'netbsd2' to the tuple
and it passes

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:32

Message:
Logged In: YES 
user_id=1188172

Fixed in rev. 42513, 42514.

--

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

[ python-Bugs-1345313 ] Python 2.4 and 2.3.5 won't build on OpenBSD 3.7

[SourceForge.net]

Bugs item #1345313, was opened at 2005-11-01 22:37
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&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: Pending
Resolution: None
Priority: 5
Submitted By: Dan (catdude)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4 and 2.3.5 won't build on OpenBSD 3.7

Initial Comment:
Both Python 2.3.5 and 2.4 fail to build, and both
report the same errors. The output of configure and of
make are attached.


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 11:32

Message:
Logged In: YES 
user_id=1188172

I assume this is not Python specific, then?

--

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

Message:
Logged In: YES 
user_id=21627

Please report this as a bug to the OpenBSD developers.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&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-1379573 ] python executable optionally should search script on PATH

[SourceForge.net]

Feature Requests item #1379573, was opened at 2005-12-13 16:13
Message generated for change (Comment added) made by cconrad
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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
Submitted By: Christoph Conrad (cconrad)
Assigned to: Nobody/Anonymous (nobody)
Summary: python executable optionally should search script on PATH

Initial Comment:
I've seen that with perl - parameter -S means search
script on path. Very helpful.

--

>Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 12:10

Message:
Logged In: YES 
user_id=21338

(1)

(HKCU|HKLM)\Software\Classes\Python.File\open\command

really is

(HKCU|HKLM)\Software\Classes\Python.File\shell\open\command

(2)

with python 24 a new behaviour occurs: i try to execute the
script on the commandline, but a dialog boy appears with:

the file "[...correct complete path to the script...]" could
not be found. Again, if i prepend python.exe, everything
works as expected. windows 2000 professional.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-20 10:14

Message:
Logged In: YES 
user_id=1188172

Do you mean that the registry setting is ok, but the
parameters are not passed correctly?

--

Comment By: Christoph Conrad (cconrad)
Date: 2006-02-20 09:12

Message:
Logged In: YES 
user_id=21338

I checked the registry. It's ok. It's windows 2000.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-16 22:29

Message:
Logged In: YES 
user_id=21627

That (arguments not passed to the script) was a bug in some
versions of the Windows installer. Please verify that the
registry, at
(HKCU|HKLM)\Software\Classes\Python.File\open\command has
the value '[path]python.exe "%1" %*'. The %* part should
arrange for arguments being passed.

--

Comment By: Christoph Conrad (cconrad)
Date: 2006-01-16 11:59

Message:
Logged In: YES 
user_id=21338

> On windows, you should be able to just invoke the_script.py
> (i.e. without a preceding python.exe). Does this not work
> for you?

It works - but command line args are not given to the called
script. If i prepend python.exe, command line args are
transferred correctly.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-01-14 19:34

Message:
Logged In: YES 
user_id=21627

On windows, you should be able to just invoke the_script.py
(i.e. without a preceding python.exe). Does this not work
for you?

--

Comment By: Christoph Conrad (cconrad)
Date: 2005-12-15 23:00

Message:
Logged In: YES 
user_id=21338

i meant the windows operating system.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-15 22:40

Message:
Logged In: YES 
user_id=1188172

I don't know... if the script is in the PATH, isn't it
normally executable too?

--

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

[ python-Bugs-1323369 ] getwindowsversion() constants in sys module

[SourceForge.net]

Bugs item #1323369, was opened at 2005-10-10 23:44
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323369&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: Fixed
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: getwindowsversion() constants in sys module

Initial Comment:
In the documentation for the sys.getwindowsversion()
function, it says that the 'platform' value may be one
of four constants (specifying them by name).

However, these constants are not in the sys module
(they are in win32con from pywin32).

It would be better if either the documentation said
that the constants were available in win32con if
pywin32 is installed, or if the constants were added to
the sys module.

I personally think the latter is better since it's a
single line of code, and makes the getwindowsversion()
function more useful, but I'm not sure whether people
will want to clutter the sys module with four constants.

I'm happy to provide a patch for either behaviour, if
an appropriate developer will choose one.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 12:15

Message:
Logged In: YES 
user_id=849994

I added the numeric values to the docs in rev. 42516, 42517.

--

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

[ python-Bugs-1013800 ] No documentation for PyFunction_* (C-Api)

[SourceForge.net]

Bugs item #1013800, was opened at 2004-08-22 14:10
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&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: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Henning Günther (der_eq)
>Assigned to: Georg Brandl (gbrandl)
Summary: No documentation for PyFunction_* (C-Api)

Initial Comment:
I'm missing documentation for the PyFunction_*
api-calls. They don't appear in the documentation but
in
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/funcobject.c?rev=2.66&view=log

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 12:58

Message:
Logged In: YES 
user_id=849994

Added to the docs in rev. 42519.

--

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

[ python-Bugs-1102649 ] pickle files should be opened in binary mode

[SourceForge.net]

Bugs item #1102649, was opened at 2005-01-14 21:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Machin (sjmachin)
>Assigned to: Georg Brandl (gbrandl)
Summary: pickle files should be opened in binary mode

Initial Comment:
pickle (and cPickle):

At _each_ mention of the pickle file, the docs should say 
that it should be opened with 'wb' or 'rb' mode as 
appropriate, so that a pickle written on one OS can be 
read reliably on another.

The example code at the end of the section should be 
updated to use the 'b' flag.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 13:12

Message:
Logged In: YES 
user_id=849994

Added a note to the docs in rev. 42520, 42521.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-24 20:08

Message:
Logged In: YES 
user_id=21627

sjmachin, it seems pretty clear what to do now. Would you
volunteer to come up with a patch yourself?

--

Comment By: John Machin (sjmachin)
Date: 2005-01-19 13:51

Message:
Logged In: YES 
user_id=480138

Re Fred's question:
Refer to thread starting at 
http://mail.python.org/pipermail/python-dev/2003-
February/033362.html

Looks like the story is like this:

For pickle mode 1 or higher, always use binary mode for 
reading/writing.

For pickle mode 0, either (a) read/write in text mode and if 
moving to another OS, do so in text mode i.e. convert the line 
endings where necessary or (b) as for pickle mode 1+, stick 
with binary throughout.

Also should add a generalisation of Tim's comment re 
NotePad, e.g. something like """A file written with pickle mode 
0 and file mode 'wb' will contain lone linefeeds as line 
terminators. This will cause it to "look funny" when viewed on 
Windows or MacOS as a text file by editors like Notepad that 
do not understand this format."""

--

Comment By: Tim Peters (tim_one)
Date: 2005-01-19 13:45

Message:
Logged In: YES 
user_id=31435

Yes, binary mode should always be used, regardless of 
protocol.  Else pickles aren't portable across boxes (in 
particular, Unix can't read a protocol 0 pickle produced on 
Windows if the latter was written to a text-mode file).  "text 
mode" was a horrible name for protocol 0.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-19 05:09

Message:
Logged In: YES 
user_id=3066

In response to irmin's comment:

freopen() is only an option for real file objects; pickles
are often stored or read from other sources.  These other
sources are usually binary to begin with, fortunately,
though this issue probably deserves some real coverage in
the documentation either way.


--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-01-19 05:06

Message:
Logged In: YES 
user_id=3066

Is this true in all cases?  Shouldn't files containing text
pickles (protocol 0) be opened in text mode?  (A problem,
given that all protocols should be readable without prior
knowledge of the protocol used to write the pickle.)

--

Comment By: Irmen de Jong (irmen)
Date: 2005-01-16 15:07

Message:
Logged In: YES 
user_id=129426

Can't the pickle code just freopen() the file itself, using
binary mode?

Or is this against Python's rule "explicit is better than
implicit"

--

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

[ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wrong

[SourceForge.net]

Bugs item #1306449, was opened at 2005-09-28 03:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gregory Bond (gnbond)
>Assigned to: Georg Brandl (gbrandl)
Summary: PyString_AsStringAndSize() return value documented wrong

Initial Comment:
The C/C++ API document (latest version from docs.python.org) has:

int PyString_AsStringAndSize(   PyObject *obj, char **buffer, int 
*length)
[snip]

If string is not a string object at all, PyString_AsString() returns 
NULL 
and raises TypeError.

But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4 
source):

{
PyErr_Format(PyExc_TypeError,
 "expected string or Unicode object, "
 "%.200s found", obj->ob_type->tp_name);
return -1;
}


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-28 12:53

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/api/concrete.tex r1.67,
1.58.2.4.

--

Comment By: Gregory Bond (gnbond)
Date: 2005-09-28 06:05

Message:
Logged In: YES 
user_id=293157

Fix the summary!

--

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

[ python-Bugs-1395597 ] module os, very small doc inconsistency

[SourceForge.net]

Bugs item #1395597, was opened at 2006-01-02 21:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&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: Fixed
Priority: 1
Submitted By: tiissa (tiissa)
>Assigned to: Georg Brandl (gbrandl)
Summary: module os, very small doc inconsistency

Initial Comment:
In the description of function mknod of module os, the 
name of the node is called "filename", whereas the 
argument of mknod in the prototype is called "path".

I join a patch changing path in filename (to be 
consistent with the inline doc).

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-02 22:07

Message:
Logged In: YES 
user_id=1188172

I love priority 1 bugs!

Corrected in revision 41881, 41882.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1395597&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-03 22:12
Message generated for change (Settings changed) made by gbrandl
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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
>Assigned to: Georg Brandl (gbrandl)
>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: Georg Brandl (birkenfeld)
Date: 2005-11-24 15:39

Message:
Logged In: YES 
user_id=1188172

Corrected patch committed in rev. 41527 and 41528 (2.4).

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-11-13 10:31

Message:
Logged In: YES 
user_id=21627

The patch looks wrong: for 'I' (capital i), you va_arg
unsigned long; I think 'I' should do unsigned int instead.

A minor nit: why does it move the 'l' case (lower L)?

Apart from that, the patch looks fine.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 08:45

Message:
Logged In: YES 
user_id=1188172

Ping!

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-18 10: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 08: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: Georg Brandl (birkenfeld)
Date: 2005-09-14 20: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-1316162 ] Segmentation fault with invalid \"coding\"

[SourceForge.net]

Bugs item #1316162, was opened at 2005-10-07 20:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&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: Out of Date
Priority: 7
Submitted By: Humberto Diógenes (virtualspirit)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Segmentation fault with invalid \"coding\"

Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-

2. Run it:
python wrong_coding.py

3. Enjoy your segfault... :P

Versions tested:
 - Python 2.4.2 (Ubuntu Breezy)
 - Python 2.3.5 (Debian Sarge)


Running it directly with "python -c" gives MemoryError. Strace output:

# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or 
directory)
write(2, "MemoryError", 11MemoryError) = 11
write(2, "\n", 1
)   = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER, 
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1)   = ?


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-08 16:23

Message:
Logged In: YES 
user_id=1188172

You're right, I hadn't updated my CVS lately.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-08 07:21

Message:
Logged In: YES 
user_id=33168

Are you sure you can reproduce with 2.4 CVS branch.  I just
fixed this recently (Fix segfault with invalid coding. in
Misc/NEWS).  I can't reproduce on 2.4 CVS.  I expect this
probem exists in 2.4.2 and earlier. Checked in around
2005/10/02 at 01:48:49, bug #772896.

The memory error was fixed in CVS, but not backported. 
That's up to Anthony (release manager).

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-08 06:24

Message:
Logged In: YES 
user_id=1188172

Reproducable here with 2.4.2 and the 2.4 CVS branch. It
seems fixed in HEAD.

--

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

[ python-Bugs-1274069 ] bz2module.c compiler warning

[SourceForge.net]

Bugs item #1274069, was opened at 2005-08-26 14:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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: Extension Modules
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Georg Brandl (gbrandl)
Summary: bz2module.c compiler warning

Initial Comment:
On Python HEAD, there's a new warning while 
compiling bz2module.c (MSVC 7.1):

python\Modules\bz2module.c(1095) : warning 
C4244: '=' :
   conversion from 'Py_off_t' to 'int', possible loss of data

Looks like a legitimate complaint to me.  The line in 
question:

readsize = offset-bytesread;

Those have types int, Py_off_t, and int respectively.  Is 
it true that offset-bytesread _necessarily_ fits in an int?  
If so, a comment should explain why, and a cast should 
be added to squash the warning.  Or If the difference 
doesn't necessarily fit in an int, the code is wrong.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-03 07:50

Message:
Logged In: YES 
user_id=1188172

Applied the newest patch. The warnings should be gone now.
bz2module.c r1.26, 1.23.2.3.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 17:52

Message:
Logged In: YES 
user_id=80475

The new patch works fine on this end.

--

Comment By: Tim Peters (tim_one)
Date: 2005-08-27 17:13

Message:
Logged In: YES 
user_id=31435

Raymond, did you read the error output and verify that you're 
not suffering from the sample3.bz2 problem it explains?

"""
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
"""

Since the error you saw did come from sample3.bz2, that 
would be a good thing to check ;-)

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-27 17:02

Message:
Logged In: YES 
user_id=1188172

Tackled the two warnings (tell() should return a long int if
64 bits) with new patch.

I can't see the error in your output.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 16:31

Message:
Logged In: YES 
user_id=80475

The latest patch gives me the following:

Configuration: bz2 - Win32
Debug
Compiling...
bz2module.c
C:\py25\Modules\bz2module.c(1143) : warning C4244:
'function' : conversion from '__int64 ' to 'long ', possible
loss of data
C:\py25\Modules\bz2module.c(1143) : warning C4761: integral
size mismatch in argument; conversion supplied
 lib /out:libbz2.lib blocksort.obj   huffman.obj
crctable.objrandtable.obj   compress.obj   
decompress.obj  bzlib.obj
Microsoft (R) Library Manager Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
 cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2
bzip2.c libbz2.lib setargv.obj
bzip2.c
 cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o
bzip2recover bzip2recover.c
bzip2recover.c
 type words1
Doing 6 tests (3 compress, 3 uncompress) ...
If there's a problem, things might stop at this point.
 
 .\\bzip2 -1  < sample1.ref > sample1.rb2
 .\\bzip2 -2  < sample2.ref > sample2.rb2
 .\\bzip2 -3  < sample3.ref > sample3.rb2
 .\\bzip2 -d  < sample1.bz2 > sample1.tst
 .\\bzip2 -d  < sample2.bz2 > sample2.tst
 .\\bzip2 -ds < sample3.bz2 > sample3.tst
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
 fc sample1.bz2 sample1.rb2
Comparing files sample1.bz2 and sample1.rb2
FC: no differences encountered
 fc sample2.bz2 sample2.rb2
Comparing files sample2.bz2 and sample2.rb2
FC: no differences encountered
 fc sample3.bz2 sample3.rb2
Comparing files sample3.bz2 and sample3.rb2
** sample3.bz2
BZh31AY&SYºÍ3É
·ïuU‰©´`†Û2 [EMAIL PROTECTED]
‹¾Œàý£^‘1 ˯ðú£¦Ç“º™€•)„ëô·alèDh3H¯‘Ú\mIL´hiiȕB°Ró
** sample3.rb2
BZh31AY&SY›îÜ>
ò#óAŠJ3ù²ªÔ©zÉêè7UÎ{ýÍC2 
‹l
}ۇ**
 fc sample1.tst sample1.ref
Comparing files sample1.tst and sample1.ref
FC: no differences encountered
 fc sample2.tst sample2.ref
Comparing files sample2.tst and sample2.ref
FC: no differences encount

[ python-Bugs-1394868 ] doc errata

[SourceForge.net]

Bugs item #1394868, was opened at 2006-01-01 16:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394868&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: Fixed
Priority: 5
Submitted By: Chad Whitacre (whit537)
>Assigned to: Georg Brandl (gbrandl)
Summary: doc errata

Initial Comment:
lib/node235.html -- opened as a text files
lib/module-logging.html -- an event, an LogRecord instance
lib/typessseq-strings.html -- The length modifier may
be h, l, and L may be present
lib/bltin-file-objects.html -- possibilities include
that file may

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-01 21:36

Message:
Logged In: YES 
user_id=1188172

Thanks for pointing them out, fixed in rev. 41862/41863.

--

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

[ python-Bugs-1262320 ] minidom.py alternate newl support is broken

[SourceForge.net]

Bugs item #1262320, was opened at 2005-08-17 17:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262320&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.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Whitley (jwhitley)
>Assigned to: Georg Brandl (gbrandl)
Summary: minidom.py alternate newl support is broken

Initial Comment:
In minidom.py, class Document and a few other nodes
have hardcoded newlines ('\n') remaining, causing the
"newl" parameter to potentially produce a file with
mixed line endings, e.g. if newl is set to Windows line
endings ("\r\n" ).
A diff follows which fixes all instances of the problem
of which I'm aware.

*** /usr/lib/python2.4/xml/dom/minidom.py.orig  Tue Aug
16 17:38:40 2005
--- /usr/lib/python2.4/xml/dom/minidom.py.new   Tue Aug
16 17:38:40 2005
***
*** 1286,1292 
  writer.write(" [")
  writer.write(self.internalSubset)
  writer.write("]")
! writer.write(">\n")
  
  class Entity(Identified, Node):
  attributes = None
--- 1286,1292 
  writer.write(" [")
  writer.write(self.internalSubset)
  writer.write("]")
! writer.write(">%s" % newl)
  
  class Entity(Identified, Node):
  attributes = None
***
*** 1739,1747 
  def writexml(self, writer, indent="",
addindent="", newl="",
   encoding = None):
  if encoding is None:
! writer.write('\n')
  else:
! writer.write('\n' % encoding)
  for node in self.childNodes:
  node.writexml(writer, indent, addindent,
newl)
  
--- 1739,1747 
  def writexml(self, writer, indent="",
addindent="", newl="",
   encoding = None):
  if encoding is None:
! writer.write('%s' %
newl)
  else:
! writer.write('%s' % (encoding,newl))
  for node in self.childNodes:
  node.writexml(writer, indent, addindent,
newl)
  


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 22:14

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Lib/xml/dom/minidom.py
r1.53, 1.52.4.1.

--

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

[ python-Bugs-1261229 ] __new__ is class method

[SourceForge.net]

Bugs item #1261229, was opened at 2005-08-16 18:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261229&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: Invalid
Priority: 5
Submitted By: Mike Orr (hierro)
>Assigned to: Georg Brandl (gbrandl)
Summary: __new__ is class method

Initial Comment:
Section 3.3.1 of the Language Reference says,
" __new__() is a static method"

But it's actually a class method since it's first
argument is the class.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-26 12:56

Message:
Logged In: YES 
user_id=1188172

Okay, reverted in Doc/ref/ref3.tex 1.128, 1.121.2.7.

--

Comment By: Michael Hudson (mwh)
Date: 2005-08-26 09:47

Message:
Logged In: YES 
user_id=6656

Argh!  Confusing as it is, __new__ really *is* a static method:

>>> class C(object):
...  def __new__(cls, name, bases, ns):
...   pass
... 
>>> C.__dict__['__new__']


so please revert this.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 21:57

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/ref/ref3.tex r1.127,
1.121.2.6.

--

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

[ python-Bugs-1266296 ] Mistakes in decimal.Context.subtract documentation

[SourceForge.net]

Bugs item #1266296, was opened at 2005-08-22 15:43
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266296&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jim Sizelove (jsizelove)
>Assigned to: Georg Brandl (gbrandl)
Summary: Mistakes in decimal.Context.subtract documentation

Initial Comment:
The subtract method of the decimal.Context object is
misspelled as
substract
in the online html documentation for the decimal
module, section 5.6.3.


At the Python interactive prompt:
>>> import decimal
>>> help(decimal.Context.subtract)
Help on method subtract in module decimal:

subtract(self, a, b) unbound decimal.Context method
Return the sum of the two operands.


That description should read:
Returns the difference between a and b.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-22 19:36

Message:
Logged In: YES 
user_id=1188172

Thank you for the report; fixed in 2.5 and 2.4 branches as

Doc/lib/libdecimal.tex; 1.29; 1.24.2.4
Lib/decimal.py; 1.39; 1.31.2.5
Misc/cheatsheet; 1.11; 1.10.2.1


--

Comment By: George Yoshida (quiver)
Date: 2005-08-22 18:27

Message:
Logged In: YES 
user_id=671362

Same here ::
  ./Misc/cheatsheet:  x+y  x-y   addition, substraction

--

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

[ python-Bugs-1243288 ] Misuse of \"it\'s\"

[SourceForge.net]

Bugs item #1243288, was opened at 2005-07-22 19:19
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243288&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: Fixed
Priority: 5
Submitted By: Joanne Bogart (jrbogart)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Misuse of \"it\'s\"  

Initial Comment:
In section 2.3.2 of the Python online reference manual
(http://docs.python.org/ref/id-classes.html)

the text

These names are defined by the interpreter and it's
implementation 

should read

These names are defined by the interpreter and its
implementation.

General rule:  if you can't replace "it's"  by "it is"
and preserve meaning, then "it's" is wrong.

This is so trivial I hesitate to submit it.  On the
other hand, it's a shame that such generally excellent
documentation should be marred by this kind of thing.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-22 19:48

Message:
Logged In: YES 
user_id=1188172

This was already corrected in CVS HEAD. Committed to
r24-maint as ref2.tex r1.56.2.2.

--

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

[ python-Bugs-1243192 ] Incorrect documentation of re.UNICODE

[SourceForge.net]

Bugs item #1243192, was opened at 2005-07-22 16:20
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&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: Fixed
Priority: 5
Submitted By: Nik Haldimann (nhaldimann)
>Assigned to: Georg Brandl (gbrandl)
Summary: Incorrect documentation of re.UNICODE

Initial Comment:
The effects of the re.UNICODE flag are incorrectly
documented in the library reference. Currently it says
(Section 4.2.3):


U
UNICODE
Make \w, \W, \b, and \B dependent on the Unicode
character properties database. New in version 2.0.


But this flag in fact also affects \d, \D, \s, and \S
at least since Python 2.1 (I have checked 2.1.3 on
Linux, 2.2.3, 2.3.5 and 2.4 on OS X and the source of
_sre.c makes this obvious). Proof:

Python 2.4 (#1, Feb 13 2005, 18:29:12) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on
darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> not re.match(r"\d", u"\u0966")
True
>>> re.match(r"\d", u"\u0966", re.UNICODE)
<_sre.SRE_Match object at 0x36ee20>
>>> not re.match(r"\s", u"\u2001")
True
>>> re.match(r"\s", u"\u2001", re.UNICODE)
<_sre.SRE_Match object at 0x36ee20>

\u0966 is some Indian digit, \u2001 is an em space.

I propose to change the docs to:


U
UNICODE
Make \w, \W, \b, \B, \d, \D, \s, and \S dependent on
the Unicode character properties database. New in
version 2.0.


Maybe the documentation of \d, \D, \s, and \S in
section 2.4.1 of the library reference should also be
adapted.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-02 10:30

Message:
Logged In: YES 
user_id=1188172

Thanks! Committed as Doc/lib/libre.tex r1.114, r1.112.2.2.

--

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

[ python-Bugs-1250306 ] incorrect description of range function

[SourceForge.net]

Bugs item #1250306, was opened at 2005-08-02 15:01
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&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: Fixed
Priority: 5
Submitted By: John Gleeson (jgleeson)
>Assigned to: Georg Brandl (gbrandl)
Summary: incorrect description of range function

Initial Comment:
The description of the behavior of the range function

http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-56

for negative values of step appears to be incorrect:

"if step is negative, the last element is the largest start + i * step 
greater than stop."

This implies that the last element is 'start'.  I think it should say 
'smallest' instead of 'largest'. 

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-03 07:18

Message:
Logged In: YES 
user_id=1188172

Correct. Committed as Doc/lib/libfuncs.tex r1.186, r1.175.2.6.

--

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

[ python-Bugs-1238170 ] threading.Thread uses {} as default argument

[SourceForge.net]

Bugs item #1238170, was opened at 2005-07-14 12:37
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238170&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: Threads
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Georg Brandl (gbrandl)
Summary: threading.Thread uses {} as default argument

Initial Comment:
threading.Thread.__init__ uses {} as default argument
for kwargs,
shouldn't this be the usual
def __init__(...,kwargs=None,...)
if kwargs is None:
kwargs = {}

In normal cases, this is probably not a problem but it
makes it possible to f*ck things up.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-15 09:13

Message:
Logged In: YES 
user_id=1188172

Committed as Lib/threading.py r1.49.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-15 08:57

Message:
Logged In: YES 
user_id=80475

This seems reasonable to me.

Reinhold, would you like to do the honors (2.5 only)?

--

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

[ python-Bugs-1217513 ] Omission in docs for smtplib.SMTP.sendmail()

[SourceForge.net]

Bugs item #1217513, was opened at 2005-06-09 12:32
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1217513&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: Omission in docs for smtplib.SMTP.sendmail()

Initial Comment:
In Library Reference 11.12.1 SMTP Objects, the
description of the to_addrs parameter to
SMTP.sendmail() is, "a list of RFC 822 to-address strings".

In fact sendmail() also allows a single string to be
passed as to_addrs. The comment in smtplib.py says,
"to_addrs: A list of addresses to send this mail to.  A
barestring will be treated as a list with 1 address."

I suggest the Library Reference be changed to say, "a
list of RFC 822 to-address strings or a single
to-address string"


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 18:25

Message:
Logged In: YES 
user_id=1188172

Fixed by accepting patch #1227442.

--

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

[ python-Bugs-1234979 ] Lock.acquire treats only 1 as True

[SourceForge.net]

Bugs item #1234979, was opened at 2005-07-08 21:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234979&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: Threads
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Perkins (cperkins)
>Assigned to: Georg Brandl (gbrandl)
Summary: Lock.acquire treats only 1 as True

Initial Comment:
Lock.acquire takes an argument indicating whether or
not to block.

On Windows, an argument of 1 (or True) is treated as
True, and any other number is treated as False.

The problem is in PyThread_acquire_lock, in thread_nt.h.

Although I haven't tried it on any other platform,
looking at a random sample (thread_pthread.h and
thread_solaris.h), it looks to me like other platforms
do it right.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-09 15:27

Message:
Logged In: YES 
user_id=1188172

I see. Fixed as Python/thread_wince.h r2.8, r2.7.30.1.

--

Comment By: Chris Perkins (cperkins)
Date: 2005-07-09 14:43

Message:
Logged In: YES 
user_id=1142368

It looks like thread_wince.h suffers from the same problem.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 22:26

Message:
Logged In: YES 
user_id=1188172

Okay. Committed as Python/thread_nt.h r2.23.10.1, r2.24.

--

Comment By: Tim Peters (tim_one)
Date: 2005-07-08 22:10

Message:
Logged In: YES 
user_id=31435

birkenfeld, yes we should:  lock.acquire(waitflag) has been 
documented for more than a decade as treating any non-zero 
value as true, so this is a clear bug in thread_nt.h -- if 
someone was, e.g., relying on lock.acquire(2) acting like 
lock.acquire(0) on Windows, tough luck for them.  I'd even 
include this patch in a bugfix release, since the current 
meaning of lock.acquire(2) varies across platforms because 
of this bug, and that's a potentially serious problem.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:59

Message:
Logged In: YES 
user_id=1188172

Attaching a patch fixing that. Of course, the change is
slightly backwards-incompatible, so should we do that?

--

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

[ python-Bugs-1228904 ] weakref example broken

[SourceForge.net]

Bugs item #1228904, was opened at 2005-06-28 10:32
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: paolo veronelli (paolo_veronelli)
>Assigned to: Georg Brandl (gbrandl)
Summary: weakref example broken

Initial Comment:
Surely the example in python2.4/lib/weakref-objects.html
 is untested .Bad story.

Attached a working version which I suppose correct it .

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-02 17:49

Message:
Logged In: YES 
user_id=80475

It would be useful to add a testcase cover the examples in
the docs.  See test_itertools.py for an example of how that
is done.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:45

Message:
Logged In: YES 
user_id=1188172

Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1.

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 19:46

Message:
Logged In: YES 
user_id=174455

I can confirm this (in 2.5a0). It seems untested as it
contains several small errors. I have submitted a doc-patch
with working code that is also a simplified version. See
patch #1229935.

--

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

[ python-Bugs-1225705 ] os.environ documentation should mention unsetenv

[SourceForge.net]

Bugs item #1225705, was opened at 2005-06-22 18:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225705&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: Fixed
Priority: 5
Submitted By: Brian Wellington (bwelling)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.environ documentation should mention unsetenv

Initial Comment:
The (current) documentation for os.environ says:

---
If the platform supports the putenv() function, this
mapping may be used to modify the environment as well
as query the environment. putenv() will be called
automatically when the mapping is modified.
---

Some platforms (Solaris 8 and 9, at least) have
putenv() but not unsetenv(), which means that setting
environment variables by assigning values in os.environ
works, but unsetting them by deleting from os.environ
doesn't.  This is confusing, and should at least be
documented (if for no other reason than no one else
should waste several hours figuring this out).  This
was tested with Python 2.4.1 and earlier versions.

I'd suggest documenting os.unsetenv() in 6.1.1 (Process
Parameters) of the manual, and modifying the above text
to say something like:

---
If the platform supports the putenv() and unsetenv()
functions, this mapping may be used to modify the
environment as well as query the environment. putenv()
will be called automatically when an entry in the
mapping is added or changed, and unsetenv() will be
called automatically when an entry is deleted.
---

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 18:47

Message:
Logged In: YES 
user_id=1188172

Fixed as Doc/lib/libos.tex r1.158, r1.146.2.4. Thanks for
the report!

--

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

[ python-Bugs-1266283 ] lexists() is not exported from os.path

[SourceForge.net]

Bugs item #1266283, was opened at 2005-08-22 15:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1266283&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Blais (blais)
>Assigned to: Georg Brandl (gbrandl)
Summary: lexists() is not exported from os.path

Initial Comment:
I'm not quite sure if this is desired, but looking at
posixpath.py it looks like a bug:  lexists() is not in
__all__, and so

from os.path import *
...
lexists(...)

does not work.



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-22 18:08

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in 2.5 and 2.4 branches as

Lib/macpath.py; 1.52; 1.50.2.1
Lib/ntpath.py; 1.63; 1.61.2.1
Lib/os2emxpath.py; 1.15; 1.13.2.1
Lib/posixpath.py; 1.75; 1.73.2.2



--

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

[ python-Bugs-1274828 ] splitunc not documented

[SourceForge.net]

Bugs item #1274828, was opened at 2005-08-27 21:40
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274828&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Poor Yorick (pooryorick)
>Assigned to: Georg Brandl (gbrandl)
Summary: splitunc not documented

Initial Comment:
a description of splitunc is missing from

http://docs.python.org/lib/module-os.path.html

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:42

Message:
Logged In: YES 
user_id=1188172

Interesting, since splitunc() is mentioned in the chapter
heading :)

Added a description in Doc/lib/libposixpath.tex r1.43,
r1.40.2.3.

--

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

[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent

[SourceForge.net]

Bugs item #1235266, was opened at 2005-07-09 16:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Georg Brandl (gbrandl)
Summary: debug info file descriptor of tarfile is inconsistent

Initial Comment:
"7.19.1 TarFile Objects" says
  The messages are written to sys.stdout.
but they are actually written to sys.stderr ::

  def _dbg(self, level, msg):
  """Write debugging output to sys.stderr.
  """
  if level <= self.debug:
  print >> sys.stderr, msg

There are 2 options:
(a) change document from stdout to stderr.
(b) rewrite the code to use stdout.

Given this is debug messages and most other modules 
use stdout for debug printing(gc is one of the few 
exceptions?), I'm +1 on (b).

[*] http://docs.python.org/lib/tarfile-objects.html


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 07:29

Message:
Logged In: YES 
user_id=1188172

Okay. Checked in Doc/lib/libtarfile.tex r1.10, r1.7.2.1.

And when will be some day?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-12 03:06

Message:
Logged In: YES 
user_id=80475

Just change the docs to match the actual behavior.  Let's
leave the implementation alone.

There is no great need to have tarfile's implementation
match zipfile.  Someday, all of the modules will generate
messages via the logging module and you'll trivially be able
to mask them or redirect them in a consistent manner.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-11 06:19

Message:
Logged In: YES 
user_id=1188172

Attaching patches for both tarfile and zipfile. For tarfile,
the docs are changed to stderr, for zipfile, both docs and
implementation are changed to stderr.

Since I don't assume that someone actually uses the debug
info in some automated way, I think we can correct this in 2.5.

Raymond, please review.

--

Comment By: George Yoshida (quiver)
Date: 2005-07-10 16:26

Message:
Logged In: YES 
user_id=671362

OK. I tested some GNU compression/decompression tools 
and comfirmed that they write debugging messages
(displayed in verbose mode(-v)) to stderr.

Now I'm leaning toward Reinhold's idea.

> What about zipfile? 
> Should we print debug info to stderr there, too?

Maybe yes.  I'd be happy to volunteer for that patch.


--

Comment By: Lars Gustäbel (gustaebel)
Date: 2005-07-10 08:00

Message:
Logged In: YES 
user_id=642936

This is a documentation error. Debug messages must go to
stderr because that's what stderr is for. Think of a script
that writes a tar archive to stdout for use in a unix shell
pipeline. If debug messages went to stdout, too, it would
produce unusable output, because archive data and debug
messages would be mixed.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-09 17:04

Message:
Logged In: YES 
user_id=1188172

The documentation seems to be borrowed from zipfile, where
the statement is true: debug info is written to stdout.

I'm in favour of changing the docs to stderr for tarfile.
What about zipfile? Should we print debug info to stderr
there, too?

--

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

[ python-Bugs-1213894 ] os.path.realpath() cannot handle symlinks

[SourceForge.net]

Bugs item #1213894, was opened at 2005-06-03 00:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1213894&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: Fixed
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.path.realpath() cannot handle symlinks

Initial Comment:

To reproduce:

Create a link, say to /tmp:

  bagira:~/python> ls -l xxx
  lrwxrwxrwx1 ilya ilya4 2005-06-02
17:09 xxx -> /tmp/

And now:
 
  bagira:~/python> python2.4
  Python 2.4.1 (#2, May  5 2005, 11:32:06) 
  [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
  Type "help", "copyright", "credits" or "license" for
more
   information.
   >>> import os.path
   >>> os.path.realpath("xxx")
   '/home/ilya/python/xxx'

I'd expect realpath() to return "/tmp"

Note: This bug was reported earlier (e.g bug  990669)
but it was closed as fixed



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 14:32

Message:
Logged In: YES 
user_id=1188172

Fixed, thanks for the report.

Lib/posixpath.py r1.74 r1.73.2.1
Lib/test/test_posixpath.py r1.13 r1.12.2.1

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 11:27

Message:
Logged In: YES 
user_id=80475

Run the full testsuite, then
go ahead an apply the patch.
Be sure to add an entry to Misc/NEWS.



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 08:17

Message:
Logged In: YES 
user_id=1188172

Attaching new test case for this problem.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 07:58

Message:
Logged In: YES 
user_id=1188172

Confirmed. Only occurs when the symlink is the first
directory part of the argument. Attaching fix, assigning to
Raymond to check in.

--

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

[ python-Bugs-1210001 ] Typo in \"Differences from mimelib\"

[SourceForge.net]

Bugs item #1210001, was opened at 2005-05-27 16:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210001&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Zumi (zumi001)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Typo in \"Differences from mimelib\"

Initial Comment:
In the online manual:
http://www.python.org/doc/2.4/lib/node577.html
"12.2.12 Differences from mimelib" there's a typo:

"The methodgetmaintype() was renamed to get_main_type()."

Suggestion: a space after the word "method".

So something like this:
"The method getmaintype() was renamed to get_main_type()."

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:01

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; committed as Doc/lib/email.tex r1.19,
r1.18.2.1.

--

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

[ python-Bugs-1202475 ] httplib docs mentioning HTTPConnection.getreply

[SourceForge.net]

Bugs item #1202475, was opened at 2005-05-15 20:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202475&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: Fixed
Priority: 5
Submitted By: Georg Brandl (gbrandl)
>Assigned to: Georg Brandl (gbrandl)
Summary: httplib docs mentioning HTTPConnection.getreply

Initial Comment:
... instead of getresponse in the description of send().

Also, a general note or explanation like that could be
given before the description of send():

"""
You can send requests in two ways: either using the
request() method as described above, which combines all
request parameters, or using a sequence of
putrequest(), zero or more times addheader(),
endheaders() and then send().
"""

It is sort of confusing in its current state.

Oh yes, and while you're at it ;), you could add a note
that the response object must be read completely before
a new request can be sent.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 19:17

Message:
Logged In: YES 
user_id=1188172

Fixed in Doc/lib/libhttplib.tex r1.39, r1.38.2.1.

--

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

[ python-Bugs-1204734 ] __getattribute__ documentation error?

[SourceForge.net]

Bugs item #1204734, was opened at 2005-05-19 05:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: Fixed
Priority: 5
Submitted By: John Eikenberry (zhar)
>Assigned to: Georg Brandl (gbrandl)
Summary: __getattribute__ documentation error?

Initial Comment:
>From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html

"Called unconditionally to implement attribute accesses for instances of the 
class. If the class also defines __getattr__, it will never be called (unless 
called explicitly)."

But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux.

class A(object):

def __getattr__(self,key):
print '__getattr__',key
raise AttributeError,key

def __getattribute__(self,key):
print '__getattribute__',key
raise AttributeError,key

a = A()
a.foo

$ python test.py
__getattribute__ foo
__getattr__ foo
Traceback (most recent call last):
  File "test.py", line 14, in ?
a.foo
  File "test.py", line 7, in __getattr__
raise AttributeError(key)
AttributeError: foo

It seems to be calling __getattribute__ as it should, but then it falls back on 
__getattr__ even though the docs specifically say it shouldn't.



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:30

Message:
Logged In: YES 
user_id=1188172

Checked in my patch as Doc/ref/ref3.tex r1.125, r1.121.2.4.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:03

Message:
Logged In: YES 
user_id=1188172

Attached a documentation patch, following Terry's wording.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 17:42

Message:
Logged In: YES 
user_id=593130

If I understand correctly, this revision of the consequent of the 
second sentence (after ',') matches the implementation.

[If the class also defines __getattr__, ]
the latter will not be called unless __getattribute__ either calls it 
explicitly or raises an AttributeError.


--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-05-26 16:18

Message:
Logged In: YES 
user_id=6380

The implementation works as expected.

The documentation is flawed.

--

Comment By: John Eikenberry (zhar)
Date: 2005-05-26 15:52

Message:
Logged In: YES 
user_id=322022

Terry, I started with a much longer subject but decided I
didn't want to overload it to much. Guess I went to far the
other way. I'll try to strike a better balance next time.

Thanks.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 15:43

Message:
Logged In: YES 
user_id=593130

John E: A general title like 'Documentation Error?' discourages 
attention from people with the specialized knowledge needed to 
answer such a question.  I have taken the liberty of trying to 
add '__getattribute__'.  We'll see if the edit works when I, not the 
OP, submits it.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 15:33

Message:
Logged In: YES 
user_id=593130

If the default __getattribute__ explicitly calls __getattr__ (but I 
don't know which source file to check), then the second 
sentence above *would* make some sense.

Guido (or deputy): what is your design intention?

Note: if the second sentence is kept, replacing 'it' with 'the latter' 
would make it clearer. I first read 'it' as referring to 
__getattribute__.

--

Comment By: Armin Rigo (arigo)
Date: 2005-05-24 09:08

Message:
Logged In: YES 
user_id=4771

I'll wait for an "authorized" confirmation, but so far I think that the current 
implementation is really how it is supposed to work.  The method 
'object.__getattribute__' must be there, given that it is a common technique to 
use it directly in overridden __getattribute__ implementations.  As a 
consequence, __getattribute__ cannot completely shadow __getattr__, or 
__getattr__ would never be called.

--

Comment By: John Eikenberry (zhar)
Date: 2005-05-23 18:43

Message:
Logged In: YES 
user_id=322022

Please specify in the documentation whether this is how it
is supposed to work or whether this is a side-effect of the
implementation. To make explicit if you can write cod

[ python-Bugs-1192315 ] \'clear -1\' in pdb

[SourceForge.net]

Bugs item #1192315, was opened at 2005-04-29 10:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&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: Fixed
Priority: 5
Submitted By: Pechkin (mpech)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \'clear -1\' in pdb

Initial Comment:
Delete breakpoints like in %subj% is great feature, but
wrong.
Add additional check like in do_enable()
if not (0 <= i < len(bdb.Breakpoint.bpbynumber)):

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 09:04

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Lib/pdb.py 1.74, 1.73.2.1.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:04

Message:
Logged In: YES 
user_id=80475

For the print statement, I would have used something simpler:

  print 'No breakpoint numbered', i


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:11

Message:
Logged In: YES 
user_id=1188172

Attached patch which implements the check.

--

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

[ python-Bugs-1196315 ] WeakValueDictionary.__init__ is backwards

[SourceForge.net]

Bugs item #1196315, was opened at 2005-05-06 01:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1196315&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: Fixed
Priority: 5
Submitted By: Pavel Pergamenshchik (ppergame)
>Assigned to: Georg Brandl (gbrandl)
Summary: WeakValueDictionary.__init__ is backwards

Initial Comment:
>>> from weakref import WeakValueDictionary as wvd
>>> class A:
... pass
... 
>>> wvd({1:A()})
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/weakref.py", line 46, in
__init__
UserDict.UserDict.__init__(self, *args, **kw)
  File "/usr/lib/python2.4/UserDict.py", line 7, in
__init__
self.update(dict)
  File "/usr/lib/python2.4/weakref.py", line 161, in update
d[key] = KeyedRef(o, self._remove, key)
AttributeError: WeakValueDictionary instance has no
attribute '_remove'


WeakValueDictionary.__init__ calls UserDict.__init__
first and sets self._remove second. It should do it the
other way around. This is a regression from 2.3.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 09:21

Message:
Logged In: YES 
user_id=1188172

Thanks for the report. Committed as Lib/weakref.py r1.27
r1.26.2.1.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 07:19

Message:
Logged In: YES 
user_id=1188172

Okay to checkin?

--

Comment By: Mike C. Fletcher (mcfletch)
Date: 2005-05-11 19:23

Message:
Logged In: YES 
user_id=34901

I would agree that the order is definitely broken.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-10 03:36

Message:
Logged In: YES 
user_id=80475

Fred, I believe this was your change (1.23).
The OP's request apprears correct to me.

--

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

[ python-Bugs-1248199 ] shelve .sync operation not documented

[SourceForge.net]

Bugs item #1248199, was opened at 2005-07-31 02:53
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248199&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Georg Brandl (gbrandl)
Summary: shelve .sync operation not documented

Initial Comment:
The shelve documentation doesn't describe how to flush
updates out to the disc file.  Without that, a
long-running server could go for months without writing
out any updates.  A server crash would then lose every
update.  I asked on clpy whether shelve really had such
a severe deficiency.  Thanks to Robert Kern for
mentioning the .sync() method, which does what is
needed.  The doc should definitely mention this. 
Shelve is much less useful without it.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 22:40

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libshelve.py r1.23,
1.20.16.2.

--

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

[ python-Bugs-1207379 ] class property fset not working

[SourceForge.net]

Bugs item #1207379, was opened at 2005-05-23 22:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1207379&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
Submitted By: MartinKirst (master_jaf)
>Assigned to: Georg Brandl (gbrandl)
Summary: class property fset not working

Initial Comment:
Classes which are not instantiated from 'object',
containing properties, are not working as expected. The
GET method is working but not the SET method. Tested
with python 2.4.1 und 2.3.5.
See sample code file.

--

Comment By: MartinKirst (master_jaf)
Date: 2005-08-21 20:55

Message:
Logged In: YES 
user_id=1140154

I agree with rhettinger, that there is no need to put
advanced things like properties in the tutorial.

But I still think, that the property explanation in "Python
Lib. Ref."
could be a bit more precise.
IMHO it's not enough to say "Return a property attribute for
new-style classes..." because it does not prohibit
explicitly the usage in "old style classes".

Suggestion:

"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
  []
New in Python 2.2. Properties only can be applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-21 14:17

Message:
Logged In: YES 
user_id=1188172

What am I to do? Correct the patch and apply, or close this
as Rejected?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 11:35

Message:
Logged In: YES 
user_id=80475

Stay close to the definition in the tutorial's glossary:

"""
new-style class 
Any class that inherits from object. This includes all
built-in types like list and dict. Only new-style classes
can use Python's newer, versatile features like __slots__,
descriptors, properties, __getattribute__(), class methods,
and static methods. 
"""

Also, the 2.2 comment should be in standard form markup: 
\versionadded{}

"classes" ==> "class"

Overall, -0 on the update.  Ideally, the tutorial should be
kept free of the more advanced concepts like properties,
static methods, descriptors, and whatnot.  

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 10:27

Message:
Logged In: YES 
user_id=1188172

Attaching a patch for the Tutorial. It adds the following
sentence:

+Note that with Python 2.2, a new kind of classes was
introduced:
+A class deriving from \class{object} is called a
\emph{new-style class}.
+The differences to classic classes are mostly internal, but
there are
+some features (like properties and static methods) that are
only
+available for new-style classes.
+


--

Comment By: MartinKirst (master_jaf)
Date: 2005-05-26 18:59

Message:
Logged In: YES 
user_id=1140154

>From my point of view (I'm just learning Python) there is only a
simple difference between old and new style classes, just the
(object) while defining a class.
For sure, we can close this. My questions were answered :-)

So my suggestions for adding info to the documentation:

"Python Tutorial": Chap. 9.3., ex.
With Python 2.2 new style classes were introduced. These new 
style classes are inherited from 'object' base class and
supporting
newer features like properties, slots etc.. It is
recommended to use
new style classes.

"Python Library Reference": Chap. 2.1 Built-in Functions, ex.
property([fget[, fset[, fdel[, doc)
  []
New in Python 2.2. Properties only can applied to new style
classes. See also "D. Glossary" -> new style classes for more
details.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 16:37

Message:
Logged In: YES 
user_id=593130

For people who learned Python with old-style classes, it 
is 'obvious' that properties are a new addition that came with and 
work with new-style classes.  Can you suggest specific places in 
the docs where clarification could be made?  Or should be close 
this?

(I suspect that setting is more complicated than getting but would 
not have expected even the get method to work.)

--

Comment By: MartinKirst (master_jaf)
Date: 2005-05-24 12:27

Message:
Logged In: YES 
user_id=1140154

After reading some more documentation I've found at Python
Tutorial "D. Glossary" more hints.

Any class that inh

[ python-Bugs-1190563 ] os.waitpid docs don\'t specify return value for WNOHANG

[SourceForge.net]

Bugs item #1190563, was opened at 2005-04-26 20:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190563&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: Fixed
Priority: 5
Submitted By: jls (apjenkins)
>Assigned to: Georg Brandl (gbrandl)
>Summary: os.waitpid docs don\'t specify return value for WNOHANG

Initial Comment:
The library documentation for os.waitpid() does not
specify what the return value should be if the
os.WNOHANG flag is given, and the process still hasn't
exited.  

p, v = os.waitpid(pid, os.WNOHANG)

Through trial and error I discovered that in this case,
os.waitpid returns the tuple (0, 0) if pid is still
running.  This should be in the documentation for
os.waitpid().



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 19:55

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libos.tex r1.160,
r1.146.2.6.

--

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

[ python-Bugs-1215928 ] Large tarfiles cause overflow

[SourceForge.net]

Bugs item #1215928, was opened at 2005-06-06 19:19
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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: Fixed
Priority: 5
Submitted By: Tom Emerson (tree)
>Assigned to: Georg Brandl (gbrandl)
Summary: Large tarfiles cause overflow

Initial Comment:
I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 
million documents. I have a script which opens this file with "r:bz2" 
and is simply iterating over the contents using next(). With 2.4.1 I 
still get an Overflow error (originally tried with 2.3.5 as packaged in 
Mac OS 10.4.1):

Traceback (most recent call last):
  File "extract_part.py", line 47, in ?
main(sys.argv)
  File "extract_part.py", line 39, in main
pathnames = find_valid_paths(argv[1], 1024, count)
  File "extract_part.py", line 13, in find_valid_paths
f = tf.next()
  File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next
self.fileobj.seek(self.offset)
OverflowError: long int too large to convert to int


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 13:11

Message:
Logged In: YES 
user_id=1188172

I just realized that I accidentally committed the patch
together with the fix for #1191043.

Modules/bz2module r1.25, r1.23.2.2.

--

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

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply.

As for generalising Py_off_t: there are some issues which I
keep forgetting. fpos_t is not guaranteed to be an integral
type, and indeed, on Linux, it is not. I'm not quite
completely sure why this patch works; I think that on all
platforms where fpos_t is not integral, off_t happens to be
large enough. The only case where off_t is not large enough
is (IIRC) Windows, where fpos_t can be used.

So this is all somewhat muddy, and if this gets generalized,
a more elaborate comment seems to be in order.

--

Comment By: Viktor Ferenczi (complex)
Date: 2005-06-20 23:44

Message:
Logged In: YES 
user_id=142612

The bug has been reproduced with a 90Mbytes bz2 file containing more than 
4Gbytes of fairly similar documents. I've diagnosed the same problem with large 
offsets. Thanks for the patch.

Platform: WinXP Intel P4, Python 2.4.1

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-18 22:05

Message:
Logged In: YES 
user_id=80475

Martin, please look at this when you get a chance.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 21:26

Message:
Logged In: YES 
user_id=1188172

I looked into this a bit further, and noticed the following:

The modules bz2, cStringIO and mmap all use plain integers
to represent file offsets given to or returned by seek(),
tell() and truncate().

They should be corrected to use a 64-bit type when having
large file support. fileobject.c defines an own type for
that, Py_off_t, which should be shared among the other modules.

Conditional compile is needed since different
macros/functions must be used.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-13 01:32

Message:
Logged In: YES 
user_id=80475

Is there a way to write a test for this?
Can it be done without a conditional compile?
Is the problem one that occurs in other code outside of bz?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-10 11:45

Message:
Logged In: YES 
user_id=1188172

Attaching corrected patch.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-09 20:31

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which mimics the behaviour of normal file
objects. This should resolve the issue on platforms with
large file support.

--

Comment By: Lars Gustäbel (gustaebel)
Date: 2005-06-07 13:23

Message:
Logged In: YES 
user_id=642936

A quick look at the problem reveals that this is a bug in
bz2.BZ2File. The seek() method does not allow position
values >= 2GiB.

--

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

[ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows

[SourceForge.net]

Bugs item #1190204, was opened at 2005-04-26 12:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: 3.29 site is confusing re site-packages on Windows

Initial Comment:
Library Reference 3.29 site seems to say that
site-packages is only searched on Unix and Mac. The
relevant sentence is in the third paragraph: "For the
tail part, it uses the empty string (on Windows) or it
uses first lib/python2.4/site-packages and then
lib/site-python (on Unixand Macintosh)."

A clearer and more accurate wording would be "For the
tail part, it uses the empty string and lib/site-python
(on Windows) or it uses first
lib/python2.4/site-packages and then lib/site-python
(on Unixand Macintosh)."

The relevant code is line 187 in site.py.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:32

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Doc/lib/libsite.tex 1.28, 1.26.4.2.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:10

Message:
Logged In: YES 
user_id=80475

Before you check in doc changes, be sure to spellcheck and use:

python -m texcheck libsite.tex


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 18:24

Message:
Logged In: YES 
user_id=1188172

Fix attached; okay to checkin?

--

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

[ python-Bugs-1186072 ] tempnam doc doesn\'t include link to tmpfile

[SourceForge.net]

Bugs item #1186072, was opened at 2005-04-19 15:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1186072&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: Fixed
Priority: 5
Submitted By: Ian Bicking (ianbicking)
>Assigned to: Georg Brandl (gbrandl)
>Summary: tempnam doc doesn\'t include link to tmpfile

Initial Comment:
Both tmpnam and tempnam include references to tmpfile
(as a preferred way of using temporary files). 
However, they don't include a link to the page where
tmpfile is documented, and it is documented in a
different (non-obvious) section of the ``os`` page.  A
link to the section containing tmpfile would be helpful.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 20:44

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed in Doc/lib/libos.tex r1.161,
r1.146.2.7.

--

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

[ python-Bugs-1232768 ] Mistakes in online docs under \"5.3 Pure Embedding\"

[SourceForge.net]

Bugs item #1232768, was opened at 2005-07-05 14:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232768&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matt Smart (mcsmart)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Mistakes in online docs under \"5.3 Pure Embedding\"

Initial Comment:
I'm looking at the "5.3 Pure Embedding" page:
  http://python.org/doc/2.4.1/ext/pure-embedding.html

1.
  pFunc = PyDict_GetItemString(pDict, argv[2]);
- /* pFun: Borrowed reference */
+ /* pFunc: Borrowed reference */

2.
The code snippet in the section starting with "After initializing the 
interpreter," does not follow the code in the example.  It uses 
PyObject_GetAttrString() instead of PyObject_GetItemString(), 
which creates a new reference instead of borrowing one, and 
therefore needs a Py_XDEREF(pFunc) call that is also not in the 
initial example.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 13:18

Message:
Logged In: YES 
user_id=1188172

Okay. Fixed as Doc/ext/run-func.c r1.4.20.1, r1.5.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 13:12

Message:
Logged In: YES 
user_id=1188172

I thought the same when I first read this report. On this
HTML page, there's the large code sample at the top, and
below are explanations. In the large sample the code with
GetItemString and without Py_XDECREF. Both are OK, but
different, and that's what the reporter's problem was.

But thanks to your digging in the CVS history, I can tell
that the intended code is the second version with GetAttrString.

--

Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 12:57

Message:
Logged In: YES 
user_id=174455

Reinhold, I must confess I am confused. I'm trying to
unravel  what goes in in CVS with all the branches. It seems
this was corrected in rev. 1.5 of embedding.tex (from
2002!?). Looking at cvs (HEAD) I also see:

python/dist/src/Doc/ext/embedding.tex (line ~180):

\begin{verbatim}
pFunc = PyObject_GetAttrString(pModule, argv[2]);
/* pFunc is a new reference */

if (pFunc && PyCallable_Check(pFunc)) {
...
}
Py_XDECREF(pFunc);
\end{verbatim}

This seems to fix the problem? Also looking at 
http://python.org/doc/2.4.1/ext/pure-embedding.html *today*
I don't see 'Borrowed  reference' and but 'a new reference'
and including a PyXDEREF. Am I totally missing the point of
the bug-report or is the time-machine flying again?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 11:35

Message:
Logged In: YES 
user_id=1188172

Only the first part has been fixed. The second is beyond my
decision and must be considered by someone other.

--

Comment By: Peter van Kampen (pterk)
Date: 2005-07-12 10:59

Message:
Logged In: YES 
user_id=174455

These seem to have been fixed already in CVS (although I
can't find a duplicate report). Suggest closing.

--

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

[ python-Bugs-1191043 ] bz2 RuntimeError when decompressing file

[SourceForge.net]

Bugs item #1191043, was opened at 2005-04-27 14:34
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191043&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: Fixed
Priority: 5
Submitted By: Chris AtLee (catlee)
>Assigned to: Georg Brandl (gbrandl)
Summary: bz2 RuntimeError when decompressing file

Initial Comment:
The following code:
echo -n Testing123 | bzip2 > test.bz2
python -c "import bz2; lines =
bz2.BZ2File('test.bz2').readlines()"

produces this output:
Traceback (most recent call last):
  File "", line 1, in ?
RuntimeError: wrong sequence of bz2 library commands used

Tested on Python 2.4.1 (debian unstable - April 1
2005), and Python 2.3.5 (debian unstable - May 26 2005)

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-21 14:19

Message:
Logged In: YES 
user_id=1188172

Fixed, also for xreadlines(). Problem was that the code, if
there were no newlines in a chunk read from the file,
assumed that the buffer was too small.

Modules/bz2module.c r1.25
Lib/test/test_bz2.py r1.18

Please review the fix!

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-21 12:03

Message:
Logged In: YES 
user_id=80475

Reinhold, do you want to take this one?

--

Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-14 14:55

Message:
Logged In: YES 
user_id=11375

Calling .readline() works fine, though.  The problem wasn't
apparent with a quick look at the readlines() code.


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 12:14

Message:
Logged In: YES 
user_id=80475

Okay, I see.  Will look into it.

--

Comment By: Chris AtLee (catlee)
Date: 2005-04-28 12:00

Message:
Logged In: YES 
user_id=186532

How is test.bz2 not a valid bz2 file?  The command line tool
"bzcat" or "bunzip2" can operate properly on it.  Using
BZ2File("test.bz2").read() works properly, it's just the
readlines() call that breaks.

Try this out:
import bz2
bz2.BZ2File("test.bz2","w").write("testing123")

# This works fine
assert bz2.BZ2File("test.bz2").read() == "testing123"

# This raises a RuntimeError
assert bz2.BZ2File("test.bz2").readlines() == ["testing123"]

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-28 07:06

Message:
Logged In: YES 
user_id=80475

The looks like correct behavior to me.  The test.bz2 file is
not in a valid bz2 format.  I suspect that you've misread
the BZ2File API which is intended for reading and writing
uncompressed data to and from a file in a bz2 format (where
the data is stored in compressed form).

If this interpretation of the bug report is correct, please
mark as not-a-bug and close.

--

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

[ python-Bugs-1168746 ] frame.f_exc_type,value,traceback

[SourceForge.net]

Bugs item #1168746, was opened at 2005-03-22 23:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&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: Fixed
Priority: 4
Submitted By: Armin Rigo (arigo)
>Assigned to: Georg Brandl (gbrandl)
Summary: frame.f_exc_type,value,traceback

Initial Comment:
The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are 
misdocumented.  They are not the last exception caught by the frame, nor the 
one currently handled, or anything reasonable like that.

They give the last exception raised in the parent frame, and only if another 
exception was ever raised in the current frame (in all other cases they are 
None).

I very much doubt this is useful to anyone, so maybe un-publishing the 
attributes would be sensible, but in any case the doc needs a small fix 
(ref/types.html and the doc about and in inspect.py).

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-02 10:29

Message:
Logged In: YES 
user_id=1188172

Okay, checked in patch #1230615 as Doc/ref/ref3.tex r1.125,
r1.121.2.4.

--

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

[ python-Bugs-1175022 ] property example code error

[SourceForge.net]

Bugs item #1175022, was opened at 2005-04-01 20:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175022&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: John Ridley (ojokimu)
>Assigned to: Georg Brandl (gbrandl)
Summary: property example code error

Initial Comment:
The example code for 'property' in lib/built-in-funcs.html may 
produce an error if run "as is": 
 
Python 2.4.1 (#1, Mar 31 2005, 21:33:58) 
[GCC 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)] on linux2 
>>> class C(object): 
... def getx(self): return self.__x 
... def setx(self, value): self.__x = value 
... def delx(self): del self.__x 
... x = property(getx, setx, delx, "I'm the 'x' property.") 
... 
>>> c=C() 
>>> c.x 
Traceback (most recent call last): 
  File "", line 1, in ? 
  File "", line 2, in getx 
AttributeError: 'C' object has no attribute '_C__x' 
 
The same goes for 'del c.x' (although not 'c.x = 0', of course). 
 
A more "typical" way of defining managed attributes would be to 
include an 'init' as follows: 
 
class C(object): 
def __init__(self): self.__x = None 
def getx(self): return self.__x 
def setx(self, value): self.__x = value 
def delx(self): del self.__x 
x = property(getx, setx, delx, "I'm the 'x' property.") 
 
 

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 20:08

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; fixed as Doc/lib/libfuncs.tex r1.184,
r1.175.2.4.

--

Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 03:33

Message:
Logged In: YES 
user_id=81797

I agree, adding the __init__ to set a value would be useful.  +1

--

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

[ python-Bugs-1175848 ] poorly named variable in urllib2.py

[SourceForge.net]

Bugs item #1175848, was opened at 2005-04-03 15:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175848&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Roy Smith (roysmith)
>Assigned to: Georg Brandl (gbrandl)
Summary: poorly named variable in urllib2.py

Initial Comment:
This is kind of trivial, but in urllib2.OpenerDirector.__init__, the local 
variable "server_version" is poorly named.  The name makes it 
sound like it's the version of the HTTP (or whatever) server we're 
talking to.  How about client_version or library_version or 
module_version?


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:01

Message:
Logged In: YES 
user_id=1188172

Fixed as of Lib/urllib2.py r1.82.

--

Comment By: John J Lee (jjlee)
Date: 2005-05-19 19:10

Message:
Logged In: YES 
user_id=261020

My, you're picky. ;-)

Yes, that does seem a poor name, +1 on changing it to
client_version.


--

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

[ python-Bugs-1194181 ] bz2.BZ2File doesn\'t handle modes correctly

[SourceForge.net]

Bugs item #1194181, was opened at 2005-05-03 02:39
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194181&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: Fixed
Priority: 8
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Georg Brandl (gbrandl)
>Summary: bz2.BZ2File doesn\'t handle modes correctly

Initial Comment:
I've noticed that if I specify a file mode of 'U' to bz2.BZ2File, it will 
erase my file.  That's bad.  Specifying 'rU' works as expected.  
Basically, it assumes that you want a writable file unless it sees an 
'r' in the mode, or no mode is given.  Ugh.

I've attached a patch that fixes this on CVS HEAD, it looks like it 
should apply cleanly to 2.4 as well.  This is a backport candidate if 
I've ever seen one.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 19:47

Message:
Logged In: YES 
user_id=1188172

Ok, checked in as

Modules/bz2module.c r1.24 r1.23.2.1
Lib/test/test_bz2.py r1.17 r1.16.2.1


--

Comment By: Bob Ippolito (etrepum)
Date: 2005-06-03 18:23

Message:
Logged In: YES 
user_id=139309

It should still be OK to check in.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 18:16

Message:
Logged In: YES 
user_id=1188172

Okay to check in?

--

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

[ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME

[SourceForge.net]

Bugs item #1193849, was opened at 2005-05-02 15:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Wummel (calvin)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.path.expanduser documentation wrt. empty $HOME

Initial Comment:
If $HOME is unset, an initial "~" should not be
expanded according to the documentation. But instead it
somehow is expanded, perhaps through the pwd module:

$ env -u HOME python -c "import os.path; print
os.path.expanduser('~/foo')"
/home/calvin/foo

The result should be "~/foo" instead of "/home/calvin/foo".

I suggest adjusting the documentation to state the also
a single "~" is looked up in the pwd module, not only
"~user".

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:28

Message:
Logged In: YES 
user_id=1188172

Okay, committed as Doc/lib/libposixpath.py 1.42, 1.40.2.2.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:16

Message:
Logged In: YES 
user_id=80475

Strike the comma before the final "or".

After you post this, put a note on your todo list to check
its appearance in the HTML docs whenever Fred runs an update:
   
http://www.python.org/dev/doc/devel/


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-05 12:29

Message:
Logged In: YES 
user_id=1188172

Attached a patch which fixes the docs. Okay to checkin?

--

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

[ python-Bugs-1209560 ] spurious blank page in dist.pdf

[SourceForge.net]

Bugs item #1209560, was opened at 2005-05-27 00:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&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: Fixed
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Georg Brandl (gbrandl)
Summary: spurious blank page in dist.pdf

Initial Comment:
In the US Letter sized version of dist.pdf in the
current download zip (Python 2.4.1), the third page of
the file (the one immediately preceding the table of
contents, which starts with roman numeral "i") is
blank.  That means that page "i" of the table of
contents, and page "1" of the actual document, begin on
even-numbered pages in the file.  This is bad because
if you print on a duplex printer, page 1 comes out on
the back of page ii, page 3 comes out on the back of
page 2, etc.  You want odd numbered pages to be on the
front and even numbered pages to be on the back, so
page 2 should be on the back of page 1, etc.

This is probably a problem with the latex extension
that made the pdf file and so it probably affects the
other pdfs as well as dist.pdf, but that's the only one
I printed.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 20:12

Message:
Logged In: YES 
user_id=1188172

Thanks for the report! 
Checked in as Doc/dist/dist.tex rev 1.95, 1.86.2.5.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-04 11:12

Message:
Logged In: YES 
user_id=1188172

This indeed happens only in dist.pdf. Attaching a patch
which includes the copyright, as in all other documents, and
magically, the paging is right.

--

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

[ python-Bugs-1166582 ] IterableUserDict not in docs

[SourceForge.net]

Bugs item #1166582, was opened at 2005-03-19 18:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166582&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
>Assigned to: Georg Brandl (gbrandl)
Summary: IterableUserDict not in docs

Initial Comment:
There is no mention of UserDict.IterableUserDict in the
docs (3.7 UserDict). Here is a suggested rewrite:

class UserDict( [initialdata])
Class that simulates a dictionary. The instance's
contents are kept in a regular dictionary, which is
accessible via the data attribute of UserDict
instances. If initialdata is provided, data is
initialized with its contents; note that a reference to
initialdata will not be kept, allowing it be used for
other purposes. Note: For backward compatibility,
instances of UserDict are not iterable.

class IterableUserDict( [initialdata])
Subclass of UserDict that supports direct iteration
(e.g. "for key in myDict").

In addition to supporting the methods and operations of
mappings (see section 2.3.8), UserDict and
IterableUserDict instances provide the following attribute:

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-25 21:04

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; fixed as Doc/lib/libuserdict.tex
r1.27, r1.24.4.3.

--

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

[ python-Bugs-1155638 ] self.length shield exception in httplib

[SourceForge.net]

Bugs item #1155638, was opened at 2005-03-03 07:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&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: Fixed
Priority: 5
Submitted By: Andrew P. Lentvorski, Jr. (bsder)
>Assigned to: Georg Brandl (gbrandl)
Summary: self.length shield exception in httplib

Initial Comment:
Under certain conditions (I'm trying to open a
Shoutcast stream), I wind up with the following
exception from httplib:

 Traceback (most recent call last):
  File "/home/devel/lib/python2.4/threading.py", line
442, in __bootstrap
self.run()
  File "avalanche.py", line 86, in run
streamData = streamResponse.read(256)
  File "/home/devel/lib/python2.4/httplib.py", line
478, in read
self.length -= len(s)
TypeError: unsupported operand type(s) for -=: 'str'
and 'int'

Normally, self.length has many shields of the form "if
self.length is None:"; however, self.length gets
initialize to _UNKNOWN which is the string "UNKNOWN"
rather than None.  As such, all of the shields are useless.

Am I using a deprecated library or something?  I'm
really surprised no one else has bumped into this.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:07

Message:
Logged In: YES 
user_id=1188172

Thanks for the report! This is fixed as of Lib/httplib.py
r1.95, r1.94.2.1.

--

Comment By: Yusuke Shinyama (euske)
Date: 2005-05-10 02:46

Message:
Logged In: YES 
user_id=385990

I did bump into the same problem.
Apparently when I got HTTP/0.9 connection, self.length is
not initialized.
Inserting a line into l.362 at httplib.py (v2.4) seems to
solve this problem. I will also post a patch:

if self.version == 9:
self.chunked = 0
self.will_close = 1
self.msg = HTTPMessage(StringIO())
+self.length = None
return


--

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

[ python-Bugs-1061920 ] \"k\" specifier in PyArg_ParseTuple incomplete documentated

[SourceForge.net]

Bugs item #1061920, was opened at 2004-11-07 14:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061920&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gustavo J. A. M. Carneiro (gustavo)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \"k\" specifier in PyArg_ParseTuple incomplete documentated

Initial Comment:
Documentation for python 2.3 says:

"k" (integer) [unsigned long]
Convert a Python integer to a C unsigned long
without overflow checking. New in version 2.3.

However I was told -- and tested to be true -- that "k"
also accepts python long as argument.  This should be
mentioned in the documentation, otherwise programmers
will assume "k" only accepts values in the range
0-2^31, thus not allowing the full 'unsigned long' range.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 20:05

Message:
Logged In: YES 
user_id=1188172

Fixed as Doc/api/utilities.tex r1.22, r1.20.2.2.

--

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

[ python-Bugs-1177468 ] random.py/os.urandom robustness

[SourceForge.net]

Bugs item #1177468, was opened at 2005-04-06 01:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177468&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: Accepted
Priority: 5
Submitted By: Fazal Majid (majid)
>Assigned to: Georg Brandl (gbrandl)
Summary: random.py/os.urandom robustness

Initial Comment:
Python 2.4.1 now uses os.urandom() to seed the random
number generator. This is mostly an improvement, but
can lead to subtle regression bugs.

os.urandom() will open /dev/urandom on demand, e.g.
when random.Random.seed() is called, and keep it alive
as os._urandomfd.

It is standard programming practice for a daemon
process to close file descriptors it has inherited from
its parent process, and if it closes the file
descriptor corresponding to os._urandomfd, the os
module is blissfully unaware and the next time
os.urandom() is called, it will try to read from a
closed file descriptor (or worse, a new one opened
since), with unpredictable results.

My recommendation would be to make os.urandom() open
/dev/urandom each time and not keep a persistent file
descripto. This will be slightly slower, but more
robust. I am not sure how I feel about a standard
library function steal a file descriptor slot forever,
specially when os.urandom() is probably going to be
called only once in the lifetime of a program, when the
random module is seeded.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-04 17:17

Message:
Logged In: YES 
user_id=1188172

Committed as Lib/os.py r1.87, r1.83.2.3.

--

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

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply - both to the trunk and to 2.4. 

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-04 14:56

Message:
Logged In: YES 
user_id=80475

I'm on Windows so cannot be of much use on the patch review.
 It looks fine to me and I agree that something ought to be
done.  MvL reviewed and posted the original patch so he may
be better able to comment on this patch.  Alternatively,
Peter A. can review/approve it.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-04 14:26

Message:
Logged In: YES 
user_id=1188172

Attaching a patch for Lib/os.py, fixing this on Unix.

On Windows, a completely different method is used for
urandom, so I think it is not relevant here.

Please review.

--

Comment By: Peter Åstrand (astrand)
Date: 2005-07-04 13:01

Message:
Logged In: YES 
user_id=344921

This bug is a major problem for us as well. This bug also
breaks the subprocess module. Try, for example:

subprocess.Popen(["ls"], close_fds=1, preexec_fn=lambda:
os.urandom(4))

I agree with lcaamano; the library should NOT cache a file
descriptor by default. Correctness and robustness is more
important than speed. 

Has anyone really been able to verify that the performance
with opening /dev/urandom each time is a problem? If it is,
we could add a new function to the os module that activates
the fd caching. If you have been calling this function, you
have indicated that you are aware of the problem and will
not close the cached fd. Legacy code will continue to function. 


--

Comment By: pocket_aces (pocket_aces)
Date: 2005-06-08 22:10

Message:
Logged In: YES 
user_id=1293510

We ran across this problem when we upgraded to 2.4.  We use
python embedded in a multi-threaded C++ process and use
multiple subinterpreters.  When a subinterpreter shuts down
and the os module unloads, os._urandomfd is not closed
because it is not a file object but rather just an integer.
 As such, after a while, our process had hundreds of
dangling open file descriptors to /dev/urandom.

I would think, at the very least, if this were a file
object, it would be closed when the module was unloaded (the
deallocator for fileobject closes the file).  However, that
doesn't make it any easier for those who are forking
processes.  Probably the best bet is to close it after
reading the data.  If you need a "high performance, multiple
seek" urandom, just open /dev/urandom yourself.

Either way, this bug is not invalid and needs to be addressed.

My 2 cents..
 --J

--

Comment By: Luis P Caamano (lcaamano)
Date: 2005-04-20 13:17

Message:
Logged In: YES 
user_id=279987

[ python-Bugs-1172785 ] doctest.script_from_examples() result sometimes un-exec-able

[SourceForge.net]

Bugs item #1172785, was opened at 2005-03-29 20:50
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&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: Fixed
Priority: 5
Submitted By: Jonathan E. Guyer (jguyer)
>Assigned to: Georg Brandl (gbrandl)
Summary: doctest.script_from_examples() result sometimes un-exec-able

Initial Comment:
doctest.script_from_examples() can sometimes return results that 
cannot be passed to exec. The docstring for script_from_examples() 
itself is an example:

guyer% python2.4
Python 2.4 (#1, Mar 10 2005, 18:08:38) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> text = '''
... Here are examples of simple math.
... Python has super accurate integer addition
... >>> 2 + 2
... 5
... 
... And very friendly error messages:
... 
... >>> 1/0
... To Infinity 
... And
... Beyond
... 
... You can use logic if you want:
... 
... >>> if 0:
... ...blay 
... ...blah
... ...
... 
... Ho hum
... '''
>>> exec doctest.script_from_examples(text)
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 21
# Ho hum
  ^
SyntaxError: invalid syntax


The issue seems to be the lack of trailing '\n', which is documented 
as required by compile(), although not for exec. 

We never saw a problem with this in Python 2.3's doctest, probably 
because comment lines, such as "Ho hum", were stripped out and 
apparently adequate '\n' were appended.

Python 2.4 on Mac OS X 10.3.8

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:24

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, this is fixed as of Lib/doctest.py
r1.123, r1.120.2.2.

--

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

[ python-Bugs-1119418 ] xrange() builtin accepts keyword arg silently

[SourceForge.net]

Bugs item #1119418, was opened at 2005-02-09 16:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119418&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: Closed
Resolution: Fixed
Priority: 6
Submitted By: Martin Blais (blais)
>Assigned to: Georg Brandl (gbrandl)
Summary: xrange() builtin accepts keyword arg silently

Initial Comment:
Calling ``xrange(10, 100, step=10)`` results in a
xrange(10, 100) iterator silently.  In contrast,
``range(10, 100, step=10)`` raises an exception.  See
test program below.

Two possible fixes:
1. fix xrange() so that it returns a xrange(10, 100,
10) iterator
2. make sure that xrange() raises an exception too.



#!/usr/bin/env python

def foo( min_, max_, step=1 ):
print min_, max_, step

print ''
foo(10, 100, 10)
foo(10, 100, step=10)

print ''
print xrange(10, 100, 10)
print xrange(10, 100, step=10)

print ''
print range(10, 100, 10)
print range(10, 100, step=10)





elbow:/usr/.../lib/python2.4$ /tmp/a.py

10 100 10
10 100 10

xrange(10, 100, 10)
xrange(10, 100)

[10, 20, 30, 40, 50, 60, 70, 80, 90]
Traceback (most recent call last):
  File "/tmp/a.py", line 16, in ?
print range(10, 100, step=10)
TypeError: range() takes no keyword arguments

> /tmp/a.py(16)?()
-> print range(10, 100, step=10)
(Pdb) 
elbow:/usr/.../lib/python2.4$ 


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-26 06:45

Message:
Logged In: YES 
user_id=1188172

Committed. Must the new API function be somehow documented?

Commit report follows:

Checking in Python/getargs.c;
new revision: 2.106; previous revision: 2.105
Checking in Include/modsupport.h;
new revision: 2.42; previous revision: 2.41
Checking in Objects/rangeobject.c;
new revision: 2.55; previous revision: 2.54
Checking in Objects/setobject.c;
new revision: 1.56; previous revision: 1.55
Checking in Objects/bufferobject.c;
new revision: 2.27; previous revision: 2.26
Checking in Objects/sliceobject.c;
new revision: 2.23; previous revision: 2.22
Checking in Modules/arraymodule.c;
new revision: 2.99; previous revision: 2.98
Checking in Modules/itertoolsmodule.c;
new revision: 1.41; previous revision: 1.40
Checking in Modules/operator.c;
new revision: 2.31; previous revision: 2.30
Checking in Modules/_randommodule.c;
new revision: 1.8; previous revision: 1.7
Checking in Modules/zipimport.c;
new revision: 1.19; previous revision: 1.18
Checking in Modules/collectionsmodule.c;
new revision: 1.39; previous revision: 1.38

Checking in Python/getargs.c;
new revision: 2.102.2.3; previous revision: 2.102.2.2
Checking in Include/modsupport.h;
new revision: 2.41.4.1; previous revision: 2.41
Checking in Objects/rangeobject.c;
new revision: 2.53.2.1; previous revision: 2.53
Checking in Objects/setobject.c;
new revision: 1.31.2.4; previous revision: 1.31.2.3
Checking in Objects/bufferobject.c;
new revision: 2.26.2.1; previous revision: 2.26
Checking in Objects/sliceobject.c;
new revision: 2.22.4.1; previous revision: 2.22
Checking in Modules/arraymodule.c;
new revision: 2.97.2.1; previous revision: 2.97
Checking in Modules/itertoolsmodule.c;
new revision: 1.39.2.1; previous revision: 1.39
Checking in Modules/operator.c;
new revision: 2.29.4.1; previous revision: 2.29
Checking in Modules/_randommodule.c;
new revision: 1.7.4.1; previous revision: 1.7
Checking in Modules/zipimport.c;
new revision: 1.18.2.1; previous revision: 1.18
Checking in Modules/collectionsmodule.c;
new revision: 1.36.2.1; previous revision: 1.36


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 20:21

Message:
Logged In: YES 
user_id=1188172

Attaching a huge patch.

It introduces the function you described, and calls it in
the constructors of xrange, set, frozenset, buffer and slice.

Moreover, I found it to be necessary in objects in the
following modules:
- array (array)
- itertools (cycle, dropwhile, takewhile, islice, imap,
chain, ifilter, count, izip, repeat)
- operator (attrgetter, itemgetter)
- _random (Random)
- zipimport (zipimporter)
- collections (deque)


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-25 14:35

Message:
Logged In: YES 
user_id=80475

xrange() needs to be kept closely parallel with range() . 
Accordingly, it should not sprout keyword arguments.

For all of these, I think the solution is to raise a
TypeError when keyword arguments are supplied to
functions/types that don't handle them.

Encapsulate the logic in a new interna

[ python-Bugs-1185883 ] PyObject_Realloc bug in obmalloc.c

[SourceForge.net]

Bugs item #1185883, was opened at 2005-04-19 12:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1185883&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Kristján Valur (krisvale)
>Assigned to: Georg Brandl (gbrandl)
Summary: PyObject_Realloc bug in obmalloc.c

Initial Comment:
obmalloc.c:835
If the previous block was not handled by obmalloc, and 
the realloc is for growing the block, this memcpy may 
cross a page boundary and cause a segmentation 
fault.  This scenario can happen if a previous allocation 
failed to successfully allocate from the obmalloc pools, 
due to memory starvation or other reasons, but was 
successfully allocated by the c runtime.

The solution is to query the actual size of the allocated 
block, and copy only so much memory.  Most modern 
platforms provide size query functions complementing 
the malloc()/free() calls.  on Windows, this is the _msize
() function.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-11 06:03

Message:
Logged In: YES 
user_id=1188172

Done. Misc/NEWS r1.1193.2.61, Objects/obmalloc.c r2.53.4.1.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-10 23:07

Message:
Logged In: YES 
user_id=80475

Reinhold, would you like to do the backport?

--

Comment By: Tim Peters (tim_one)
Date: 2005-07-10 22:33

Message:
Logged In: YES 
user_id=31435

Repaired, in

Misc/NEWS 1.1312
Objects/obmalloc.c 2.54

Should be backported to 2.4 maint.

--

Comment By: Michael Hudson (mwh)
Date: 2005-05-27 09:35

Message:
Logged In: YES 
user_id=6656

Ping!

--

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 15:34

Message:
Logged In: YES 
user_id=31435

krisvale:  Thank you for the very clear explanation.  Even I 
understand this now .

We won't use _msize here -- Python has to run under dozens 
of compilers and C libraries, and it's saner to give up on 
this "optimization" completely than to introduce a rat's nest 
of #ifdefs here.  IOW, I expect the entire "if (nbytes <= 
SMALL_REQUEST_THRESHOLD)" block will go away, so 
that the platform realloc() gets called in every case obmalloc 
doesn't control the incoming block.

BTW, note that there's no plan to do another release in the 
Python 2.3 line.

--

Comment By: Kristján Valur (krisvale)
Date: 2005-04-19 15:22

Message:
Logged In: YES 
user_id=1262199

The platform is windows 2000/2003 server, single threaded C 
runtime.  I have only had the chance to do postmortem 
debugging on this but it would appear to be as you describe:  
The following page is not mapped in.  Windows doesn´t use 
the setbrk() method of heap management and doesn´t 
automatically move the break.  Rather they (the multiple 
heaps) requests pages as required.   A malloc may have 
succeeded from a different page and copying to much from 
the old block close to the boundary caused an exception 
_at_ the page boundary.
Fyi, old block was 68 bytes at 0x6d85efb8.  This block ends 
at -effc.   The new size requested was 108 bytes.  Reading 
108 bytes from this address caused an exception at address 
0x6d85f000.  As you know, reading past a malloc block 
results in undefined behaviour and sometimes this can mean 
a crash.
I have patched python locally to use MIN(nbytes, _msize(p)) 
in stead and we are about to run the modified version on our 
server cluster.  Nodes were dying quite regularly because of 
this.  I'll let you know if this changes anyting in that aspect.

Btw, I work for ccp games, and we are running the MMORPG 
eve online (www.eveonline.com)

--

Comment By: Tim Peters (tim_one)
Date: 2005-04-19 15:00

Message:
Logged In: YES 
user_id=31435

mwh:  Umm ... I don't understand what the claim is.  For 
example, what HW does Python run on where memcpy 
segfaults just because the address range crosses a page 
boundary?  If that's what's happening, sounds more like a 
bug in the platform memcpy.  I can memcpy blocks spanning 
thousands of pages on my box -- and so can you .

krisvale:  which OS and which C are you using?

It is true that this code may try to access a bit of memory 
that wasn't allocated.  If that's at the end of the address 
space, then I could see a segfault happening.  If it is, I doubt 
there's any portable 

[ python-Bugs-1072853 ] thisid not intialized in pindent.py script

[SourceForge.net]

Bugs item #1072853, was opened at 2004-11-24 23:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&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: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Niraj Bajpai (nbajpai)
>Assigned to: Georg Brandl (gbrandl)
Summary: thisid not intialized in pindent.py script

Initial Comment:
Hi there,

I am using python version 2.3.4.

For some cases when using pindent.py with -c and -e 
option as follows, the variable "thisid" does not gets 
initialized before it hits line #310 ( current, firstkw, 
lastkw, topid = indent, thiskw, thiskw, thisid), this is 
traced all the way back to line #268 (for my case it fell 
in this else clause ... didn't try to look the exact 
scenario causing this) ... adding 

thisid = '' help fix the code for my scenario. 

If this fix is good for all scenario, please roll this over to 
main line code.

Regards,
Niraj

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 20:23

Message:
Logged In: YES 
user_id=1188172

Fixed in CVS Tools/scripts/pindent.py r1.13, r1.12.12.1.

--

Comment By: Tim Peters (tim_one)
Date: 2004-12-19 22:32

Message:
Logged In: YES 
user_id=31435

ann says that because rev 1.10 mechanically converted the 
whole file from tab indents to 4-space indents.  I've never 
looked at this code, and never even used it.  I care about 
reindent.py, but not pindent.py (it's Guido's baby, BTW).  
Unassigned myself.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 22:12

Message:
Logged In: YES 
user_id=80475

Tim, cvs ann says this is your code.

--

Comment By: Niraj Bajpai (nbajpai)
Date: 2004-11-25 02:50

Message:
Logged In: YES 
user_id=1165734

I am running on solaris-8 and command I used is as follows:
pindent.py -c -e 

This is for some special cases (I do not know, haven't digged 
into) and does not happen for all the mis-formatted files.

--

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

[ python-Bugs-1108948 ] Cookie.py produces invalid code

[SourceForge.net]

Bugs item #1108948, was opened at 2005-01-25 09:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108948&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: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cookie.py produces invalid code

Initial Comment:
The code in js_output in the Morsel class in Cookie.py
produces invalid code, the scripting language should be
specified by mimetype and not by language as per
http://www.w3.org/TR/html401/interact/scripts.html

also, the javascript line is missing an ending semi-colon

attached a "patch" (new version of the function in
question)

present at least in 2.3 but still broken in current cvs 

A related matter: the existing documentation is poor,
only after a substantial amount of code reading and
googling I found out how to set attributes such as
expires and path.



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:03

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed as of Lib/Cookie.py r1.18.

I do not backport this as some code might rely on the
language HTML attribute.

--

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

[ python-Bugs-1100201 ] Cross-site scripting on BaseHTTPServer

[SourceForge.net]

Bugs item #1100201, was opened at 2005-01-11 15:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100201&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: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Paul Johnston (paj28)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cross-site scripting on BaseHTTPServer

Initial Comment:
Hi,

There is a minor XSS flaw in BaseHTTPServer, in the
default error message, if you try connecting with a bad
method name, e.g.:

pugsley:/srv/www/htdocs # telnet risk 8000
Trying 192.168.3.52...
Connected to risk.
Escape character is '^]'.
alert('hello') / HTTP/1.0

HTTP/1.0 501 Unsupported method
("alert('hello')")
Server: SimpleHTTP/0.6 Python/2.3.4
Date: Tue, 11 Jan 2005 15:02:48 GMT
Content-Type: text/html
Connection: close


Error response


Error response
Error code 501.
Message: Unsupported method
("alert('hello')").
Error code explanation: 501 = Server does not
support this operation.

Connection closed by foreign host.

This is not likely to be a major security risk, but
ideally it should be fixed. In addition it may be that
other error messages exhibit this flaw, I haven't done
a code audit.

Credit for discovery: Richard Moore

Best wishes,

Paul

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:35

Message:
Logged In: YES 
user_id=1188172

Thanks for the report. This is fixed as of
Lib/BaseHTTPServer.py r1.30, r1.29.4.1.

--

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

[ python-Bugs-1016563 ] urllib2 bug in proxy auth

[SourceForge.net]

Bugs item #1016563, was opened at 2004-08-26 07:14
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&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: Fixed
Priority: 6
Submitted By: Christoph Mussenbrock (mussenbrock)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 bug in proxy auth

Initial Comment:
in urllib2.py:

line 502 should be:
... user_pass = base64.encodestring('%s:%s' % (unquote
(user), unquote(password))).strip()

the '.strip()' is missing in the current version ("2.1").

this makes an additonal '\n' at the end of user_pass.
So there will be an empty line in the http header, which 
is buggy.

(see also line 645, where the .strip() is right in place!).

Best regards,

Christoph

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 20:33

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, committed as Lib/urllib2.py r1.85,
r1.77.2.2.

--

Comment By: Pieter Van Dyck (pietervd)
Date: 2005-06-14 15:39

Message:
Logged In: YES 
user_id=1240437

I've run into the same bug so allow me to comment.

client environment: windows XP
target: Apache/1.3.33 (Unix)

checked on: python 2.3.4, 2.3.5, 2.4.1

To reproduce:

# from urllib2 import ...
proxy = {"http":"http://user:[EMAIL PROTECTED]:port"}
opener =build_opener(ProxyHandler(proxy))
install_opener( opener )

req = Request(coolurl)
# construct 
base64string = base64.encodestring('%s:%s' % (site_user,
site_pwd))[:-1]
authheader =  "Basic %s" % base64string
req.add_header("Authorization", authheader)
urlopen( req )

Symptoms: authentication failed on coolurl (HTTPError 401)
Fix: Applying the patch solves the problem for me

It appears as if the receiving server treats the empty line
as the end of the header even though it strictly shouldn't.

HTH
Pieter

--

Comment By: Paul Moore (pmoore)
Date: 2005-01-29 21:50

Message:
Logged In: YES 
user_id=113328

The change was introduced by revision 1.32 of the file, from
patch 527518. There's no mention of removing strip() there,
so I suspect it was an accident.

The strip() is still missing in CVS HEAD. I can see the
problem, in theory (base64.encodestring returns a string
with a terminating newline). However, I cannot reproduce the
problem.

Can the original poster provide a means of verifying the
problem? It may be useful as a test case.

Regardless, the change seems harmless, and can probably be
applied. I attach a patch against CVS HEAD:

--- urllib2.py.orig 2005-01-09 05:51:49.0 +
+++ urllib2.py  2005-01-29 21:31:49.0 +
@@ -582,7 +582,8 @@
 if ':' in user_pass:
 user, password = user_pass.split(':', 1)
 user_pass = base64.encodestring('%s:%s' %
(unquote(user),
-  
unquote(password)))
+  
unquote(password))
+  ).strip()
 req.add_header('Proxy-authorization',
'Basic ' + user_pass)
 host = unquote(host)
 req.set_proxy(host, type)


--

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

[ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads

[SourceForge.net]

Bugs item #1016880, was opened at 2004-08-26 13:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&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: Closed
Resolution: Fixed
Priority: 6
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib.urlretrieve silently truncates downloads

Initial Comment:
The following script appears to be unreliable on all 
versions of Python we can find.  The file being 
downloaded is approximately 34 MB.  Browsers such as 
IE and Mozilla have no problem downloading the whole 
thing.



import urllib
import os

os.chdir('/tmp')
urllib.urlretrieve
('http://cvs.sourceforge.net/cvstarballs/boost-
cvsroot.tar.bz2',
  'boost-cvsroot.tar.bz2')


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 18:49

Message:
Logged In: YES 
user_id=1188172

Fixed wrt patch #1062060.

--

Comment By: Irmen de Jong (irmen)
Date: 2004-12-24 14:30

Message:
Logged In: YES 
user_id=129426

Suggested addition to the doc of urllib (liburllib.tex, if
I'm not mistaken):

"""

urlretrieve will raise IOError when it detects that the
amount of data available 
was less than the expected amount (which is the size
reported by a Content-Length
header). This can occur, for example, when the download is
interrupted.

The Content-Length is treated as a lower bound (just like
tools such as wget and 
Ffirefox appear to do): if there's more data to read,
urlretrieve reads more data, but 
if less data is available, it raises IOError.

If no Content-Length header was supplied, urlretrieve can
not check the size
of the data it has downloaded, and just returns it. In this
case you
just have to assume that the download was successful.
"""

--

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 20:17

Message:
Logged In: YES 
user_id=129426

a patch is at 1062060 (raises IOError when download is
incomplete)

--

Comment By: Irmen de Jong (irmen)
Date: 2004-11-07 19:47

Message:
Logged In: YES 
user_id=129426

Confirmed here (mandrakelinux 10.0, python 2.4b2)
However, I doubt it is a problem in urllib.urlretrieve,
because I tried downloading the file with wget, and got the
following:

[EMAIL PROTECTED] tmp]$ wget -S
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
--20:38:11-- 
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
   => `boost-cvsroot.tar.bz2.1'
Resolving cvs.sourceforge.net... 66.35.250.207
Connecting to cvs.sourceforge.net[66.35.250.207]:80...
connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Sun, 07 Nov 2004 19:38:15 GMT
 3 Server: Apache/2.0.40 (Red Hat Linux)
 4 Last-Modified: Sat, 06 Nov 2004 15:11:39 GMT
 5 ETag: "b63d5b-25c3808-687d80c0"
 6 Accept-Ranges: bytes
 7 Content-Length: 39598088
 8 Content-Type: application/x-bzip2
 9 Connection: close

31% [===>  
  ] 12,665,61660.78K/sETA 03:55

20:40:07 (111.60 KB/s) - Connection closed at byte 12665616.
Retrying.

--20:40:08-- 
http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2
  (try: 2) => `boost-cvsroot.tar.bz2.1'
Connecting to cvs.sourceforge.net[66.35.250.207]:80...
connected.
HTTP request sent, awaiting response...

... so the remote server just closed the connection
halfway trough! I suspect that a succesful download is sheer
luck.

Also, the download loop in urllib looks fine to me. It only
stops when the read() returns an empty result, and that
means EOF. 

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-26 20:04

Message:
Logged In: YES 
user_id=80475

Followed the same procedure (no chdir, add a hook) but
bombed out at 9.1Mb:

 . . .
(1117, 8192, 34520156)
('boost-cvsroot.tar.bz2', )

--

Comment By: Tim Peters (tim_one)
Date: 2004-08-26 18:52

Message:
Logged In: YES 
user_id=31435

Hmm.  I don't know anything about this, but thought I'd just 
try it.  Didn't chdir(), did add a reporthook:

def hook(*args):
print args

WinXP Pro SP1, current CVS Python, cable modem over a 
wireless router.  Output looked like this:

(0, 8192, 34520156)
(1, 8192, 34520156)
(2, 8192, 34520156)
...
(4213, 8192, 34520156)
(4214, 8192, 34520156)
(4215, 8192, 34520156)

Had the whole file when it ended:

> wc boost-cvsroot.tar.bz2
 125368  765656 3452

[ python-Bugs-969757 ] function and method objects confounded in Tutorial

[SourceForge.net]

Bugs item #969757, was opened at 2004-06-09 16:59
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969757&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: Fixed
Priority: 5
Submitted By: Mark Jackson (mjackson)
>Assigned to: Georg Brandl (gbrandl)
Summary: function and method objects confounded in Tutorial

Initial Comment:
In Section 9.3.2 (Class Objects) we find, right after
the MyClass example code:

"then MyClass.i and MyClass.f are valid attribute
references, returning an integer and a method object,
respectively."

However, at the end of Section 9.3.3 (Instance Objects)
we find, referring to the same example:

"But x.f is not the same thing as MyClass.f - it is a
method object, not a function object."

There are references to MyClass.f as a function or
function object in Section 9.3.4 as well.  Although
Python terminology doesn't seem to be completely
consistent around this point (in the Python 2.1.3
interpreter MyClass.f describes itself as an "unbound
method") iit seems clear that calling MyClass.f a
method object in Section 9.3.2 is, in this context, an
error.  Should be changed to "function object."

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-08 21:37

Message:
Logged In: YES 
user_id=1188172

Thanks for the report, fixed as Doc/tut/tut.tex r1.275,
r1.261.2.10.

--

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

[ python-Bugs-1007046 ] os.startfile() doesn\'t accept Unicode filenames

[SourceForge.net]

Bugs item #1007046, was opened at 2004-08-11 06:47
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&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: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Huening (huening)
>Assigned to: Georg Brandl (gbrandl)
>Summary: os.startfile() doesn\'t accept Unicode filenames

Initial Comment:
WinXP, Python 2.3.4

os.startfile() seems to have problems with Unicode
filenames. Example:

>>> import tkFileDialog
>>> import os
>>> f = tkFileDialog.askopenfilename()
>>> type(f)

>>> os.startfile(f)

Traceback (most recent call last):
  File "", line 1, in -toplevel-
os.startfile(f)
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 14-16: ordinal not in range(128)
>>> 



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-14 20:52

Message:
Logged In: YES 
user_id=1188172

Checked this in now. posixmodule.c r2.340, r2.329.2.4.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-09-01 08:27

Message:
Logged In: YES 
user_id=38388

The path looks OK, but I can't test it on Windows
(os.startfile() is only available on Windows).

A note on style: you should always try to keep lines shorter
than 80 characters, e.g.:

--- CVS-Python/Modules/posixmodule.c2005-08-15
10:15:27.0 +0200
+++ Dev-Python/Modules/posixmodule.c2005-09-01
10:23:06.555633134 +0200
@@ -7248,7 +7248,8 @@
 {
char *filepath;
HINSTANCE rc;
-   if (!PyArg_ParseTuple(args, "s:startfile", &filepath))
+   if (!PyArg_ParseTuple(args, "et:startfile",
+ Py_FileSystemDefaultEncoding,
&filepath))
return NULL;
Py_BEGIN_ALLOW_THREADS
rc = ShellExecute((HWND)0, NULL, filepath, NULL,
NULL, SW_SHOWNORMAL);



--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 05:18

Message:
Logged In: YES 
user_id=80475

I'm unicode illiterate.  Passing to MAL for review.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 21:24

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which should fix that.

--

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

[ python-Bugs-872769 ] os.access() documentation should stress race conditions

[SourceForge.net]

Bugs item #872769, was opened at 2004-01-08 01:40
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872769&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: Fixed
Priority: 5
Submitted By: seth arnold (setharnold)
>Assigned to: Georg Brandl (gbrandl)
Summary: os.access() documentation should stress race conditions

Initial Comment:
Every version of the documentation I've seen associated
with the os.access() function neglects to mention that
its use is almost always a security vulnerability.

For the versions of python that are still maintained,
I'd like to see the documentation for this function
expanded to include a paragraph very similar to the
warning given in my system's access(2) manpage:

Using access to check if a user is authorized to e.g.,
open a file before actually doing so using open(2)
creates a security hole, because the user might exploit
the short time interval between checking and opening
the file to manipulate it.

(This paragraph comes from a Debian system; if it is
more work to validate the license on this manpage for
including this paragraph here, I'd be happy to write
some new content under whatever license is required to
get a warning included.)

Of course, there are web-based documents derived from
the module's built-in documentation. It'd be keen if
whoever fixes this in the module could poke the website
document maintainer and ask them to regenerate the content.

Thanks!

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 21:10

Message:
Logged In: YES 
user_id=1188172

Thanks for the suggestion. Committed as Doc/lib/libos.tex
r1.163, r1.146.2.9.

--

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

[ python-Bugs-1015140 ] \"article id\" in description of NNTP objects

[SourceForge.net]

Bugs item #1015140, was opened at 2004-08-24 10:26
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&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: Fixed
Priority: 5
Submitted By: Felix Wiemann (felixwiemann)
>Assigned to: Georg Brandl (gbrandl)
>Summary: \"article id\" in description of NNTP objects

Initial Comment:
lib/nntp-objects.html uses the term "article id"
several times.  This term is ambiguous though.  Either
"article number" or "message id" should be used.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 20:27

Message:
Logged In: YES 
user_id=1188172

Corrected in docs and docstrings as
Lib/nntplib.py r1.40, r1.39.2.1
Doc/lib/libnntplib.tex r1.33, r1.32.2.1

--

Comment By: Felix Wiemann (felixwiemann)
Date: 2004-08-30 20:13

Message:
Logged In: YES 
user_id=1014490

> Patches are welcome.

I don't have enough time (and I don't care enough) to write
a patch for this, currently.

> If you have a link to authoritive
> guidance, that would be nice also.

The only occurence of the case-insensitive regex
'article.id' in all RFCs is in RFC 977, which says:

223 n a article retrieved - request text separately
(n = article number, a = unique article id)

(Here, it probably means message-id.)

There are frequent occurences of 'article number' and
'message-id' in the NNTP related RFCs 977 and 2980.

So 'article id' probably should be avoided, as it is
ambiguous.  (The docs sometimes use it in the sense of
'message-id' and sometimes as 'article number', from what I
could see.)

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-29 08:20

Message:
Logged In: YES 
user_id=80475

Patches are welcome.  If you have a link to authoritive
guidance, that would be nice also.

--

Comment By: Felix Wiemann (felixwiemann)
Date: 2004-08-29 08:11

Message:
Logged In: YES 
user_id=1014490

Same problem for the docstrings in the source file
Lib/nntplib.py.

--

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

[ python-Bugs-957505 ] SocketServer module documentation misleading

[SourceForge.net]

Bugs item #957505, was opened at 2004-05-20 16:42
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jon Giddy (jongiddy)
>Assigned to: Georg Brandl (gbrandl)
Summary: SocketServer module documentation misleading

Initial Comment:
The Python Library Reference page for the SocketServer
module refers to RequestHandlerClass as though it was
the name of an actual class. Actually, it should be
either "request handler class" or "BaseRequestHandler".

Secondly, in the second para of the BaseRequestHandler
handle() method description, StreamRequestHandler and
DatagramRequestHandler are referred to as mix-in
classes when they are in fact subclasses of
BaseRequestHandler.

This error is also present in the comments at the start
of the module.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 07:39

Message:
Logged In: YES 
user_id=1188172

Thanks for the suggestions. Your first point has already
been clarified by adding more explanation to the docs, the
second point I have corrected in
Doc/lib/libsocksvr.tex r1.20, r1.18.4.2, Lib/SocketServer.py
r1.40, r1.37.4.1.

--

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

[ python-Bugs-999767 ] Setup.local ignored by setup.py

[SourceForge.net]

Bugs item #999767, was opened at 2004-07-28 22:06
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
>Assigned to: Georg Brandl (gbrandl)
Summary: Setup.local ignored by setup.py

Initial Comment:
This applies to Python 2.2.x, 2.3.x, and 2.4a1.

Platforms seem to be all Unix flavors.

I have zlib, readline, and Tk in an unusual location.
There are also often older versions in the usual
locations (/usr/local/lib, etc.). I put -L and -I flags
pointing to the desired location of these libraries in
entries for the appropriate extension modules in
Setup.local, per the README. I specify all three
extension modules as *shared* .

When I build, the extension modules I specify in
Setup.local get built twice: once directly from the
Makefile, with the flags I request in Setup.local, then
again from setup.py's build_ext phase, with the default
flags. The second build is what's installed, so I end
up using the wrong version of libz, libreadline, and
libtk .

The problem appears to be around line 152 of setup.py
(CVS revision 1.190). There is code to ignore modules
defined in Modules/Setup, but not modules defined in
Modules/Setup.local .

I'm not familiar with the text_file.TextFile class, so
there may be a better way to do this, but one the fix
is to loop over ['Modules/Setup',
'Modules/Setup.local'] rather than only reading
Modules/Setup.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-27 18:24

Message:
Logged In: YES 
user_id=1188172

Fixed in rev. 41837/41838.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-12-27 18:17

Message:
Logged In: YES 
user_id=21627

I agree; go ahead and make that change.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-27 17:38

Message:
Logged In: YES 
user_id=1188172

I think that's reasonable. Martin?

--

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

[ python-Bugs-839151 ] attempt to access sys.argv when it doesn\'t exist

[SourceForge.net]

Bugs item #839151, was opened at 2003-11-10 10:56
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Georg Brandl (gbrandl)
>Summary: attempt to access sys.argv when it doesn\'t exist

Initial Comment:
When using Python as an extension to another program,
giving a warning message attempts to access sys.argv
while it doesn't exist.

The problem can be reproduced with Vim when compiled
with Python 2.3.  Use these two commands:
:py import sys
:py print sys.maxint + 1

The problem is caused by the warnings module.  In line
53 it accesses sys.argv[0], but for an embedded
interpreter this doesn't exist.

The suggested fix does an explicit test for the
existence of sys.argv.  That seems to be the cleanest
solution to me.

This problem also existed in Python 2.2.  I didn't try
other versions.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 22:55

Message:
Logged In: YES 
user_id=1188172

Thanks for the report; this is fixed as of Lib/warnings.py
r1.27, r1.24.2.2.

--

Comment By: Nobody/Anonymous (nobody)
Date: 2003-11-19 05:23

Message:
Logged In: NO 

Much simplier test:

>>> import sys
>>> del sys.argv
>>> sys.maxint+1
Traceback (most recent call last):
  File "", line 1, in ?
  File "D:\development\python22\lib\warnings.py", line 38,
in warn
filename = sys.argv[0]
AttributeError: 'module' object has no attribute 'argv'


--

Comment By: Nobody/Anonymous (nobody)
Date: 2003-11-19 05:22

Message:
Logged In: NO 

Much simplier test:

>>> import sys
>>> del sys.argv
>>> sys.maxint+1
Traceback (most recent call last):
  File "", line 1, in ?
  File "D:\development\python22\lib\warnings.py", line 38,
in warn
filename = sys.argv[0]
AttributeError: 'module' object has no attribute 'argv'


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-11-10 15:02

Message:
Logged In: YES 
user_id=33168

Just to provide a reference, 839200 was a duplicate of this
report.  I closed 839200.

--

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

[ python-Bugs-868706 ] Calling builtin function \'eval\' from C causes seg fault.

[SourceForge.net]

Bugs item #868706, was opened at 2004-01-01 03:41
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Zac Evans (karadoc)
>Assigned to: Georg Brandl (gbrandl)
>Summary: Calling builtin function \'eval\' from C causes seg fault.

Initial Comment:
Using C to get the eval function from builtins then call it 
causes a Seg-Fault.
I've tried calling it using
PyObject_CallObject, "_CallFunction, "_CallFunctionObjArg
s.
All cause the same problem.
Other builtin functions seem to work correctly.
and eval seems to work correctly from python 
(obviously).
It's just calling eval from C which causes the crash.

Attached is some sample code which demonstrates the 
problem.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-09-15 10:47

Message:
Logged In: YES 
user_id=1188172

I fixed this; eval() now raises a TypeError when called from
C without globals/locals.

Committed in Python/bltinmodule.c r2.325, r2.318.2.3.

--

Comment By: Zac Evans (karadoc)
Date: 2004-01-02 03:04

Message:
Logged In: YES 
user_id=117625

In my opinion, the 'bug' isn't really a big problem. If it is nicer 
for the internals of Python if the bug isn't fixed, than that 
would be fine. Although, it would be a good thing to 
document somewhere. Ideally, the call should raise an 
expection saying what the problem is. That's always nicer 
than a seg-fault.

Also, on an almost unrelated note, why are
PyEval_EvalCode() and a whole lot of other PyEval_* 
functions missing from the Python/C API index in the docs 
(http://www.python.org/doc/current/api/genindex.html)?

And that's about all I have to say about that.
Thank you for you time and quick reponse.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-01 21:52

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem, but I'm not sure this
should be applied.  Partially because I'm not sure it's the
best solution.  I'm also not sure if your use should be
considered correct.  I'm not sure if this is documented. 
Perhaps that should be changed?

I understand your complaint, however, you can fix the
problem my passing a dictionary for globals.  You can also
call PyEval_EvalCode or PyEval_EvalCodeEx.  But in both of
those cases you will need to supply globals.

I believe the reason for the segfault is that globals is
NULL since there is no frame.

--

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

[ python-Bugs-755617 ] os module: Need a better description of " mode"

[SourceForge.net]

Bugs item #755617, was opened at 2003-06-17 00:13
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
>Assigned to: Georg Brandl (gbrandl)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page  says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 08:17

Message:
Logged In: YES 
user_id=1188172

Added this note to the chmod docs:

Although Windows supports chmod, you can only set the
file's read-only flag with this function (via the
\code{S_IWRITE}
and \code{S_IREAD} constants or a corresponding integer value).
All other bits are ignored.

Doc/lib/libos.tex r1.164, r1.146.2.10.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-05 18:28

Message:
Logged In: YES 
user_id=1188172

I think the wording suggested by logistix would be a good
addition to the docs.

--

Comment By: Grant Olson (logistix)
Date: 2003-06-17 19:31

Message:
Logged In: YES 
user_id=699438

Something like:

"NOTE: Although Windows supports chmod, it incorporates 
much different functionality than a typical Unix user would 
expect.  Please refer to Microsoft’s documentation for more 
details."

would be nice.

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 15:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 14:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

--

Comment By: Grant Olson (logistix)
Date: 2003-06-17 05:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 03:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 03:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

--

Comment By: Grant Olson (logistix)
Date: 2003-06-17 02:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms either (although I

[ python-Bugs-1021621 ] use first_name, not first, in code samples

[SourceForge.net]

Bugs item #1021621, was opened at 2004-09-03 05:27
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021621&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: Feature Request
Status: Closed
Resolution: Fixed
Priority: 1
Submitted By: Steve R. Hastings (steveha)
>Assigned to: Georg Brandl (gbrandl)
Summary: use first_name, not first, in code samples

Initial Comment:
Low priority documentation request.


I'm studying the documentation on how to write a C module.

http://docs.python.org/ext/node22.html

Please update the sample code in the documentation to
use "first_name" rather than "first" and "last_name"
rather than "last".

When I first studied the code and saw "first" and
"last" members in a structure, I thought those were for
a linked list of some sort.  Much later in the code I
realized that the object was supposed to have a first
name and a last name, and there was no linked list at all.

"first_name" would be much more self-documenting than
"first".  An acceptable alternative would be a comment
after the "first" declaration, saying: /* first name */

This is a small point, but I think it would be an
improvement to the documentation.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 21:20

Message:
Logged In: YES 
user_id=1188172

While mwh's new docs are in the making, I added the comments
you suggested as Doc/ext/noddy2.c r1.5.4.1, r1.6.

--

Comment By: Michael Hudson (mwh)
Date: 2004-09-03 10:59

Message:
Logged In: YES 
user_id=6656

FWIW, I agree.  I'm attempting to rewrite the extending and 
embedding manual, and yes, this is one of the things I've changed.

I've just uploaded my latest draft to

   http://starship.python.net/crew/mwh/toext/

which gets a little way into the area of defining new types.  I'd 
really appreciate your comments! (to [EMAIL PROTECTED], please).

--

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

[ python-Bugs-890010 ] Odd warning behaviors

[SourceForge.net]

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Georg Brandl (gbrandl)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
 warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
 if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
 warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
 raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > (1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-18 18:38

Message:
Logged In: YES 
user_id=1188172

I fixed warnings inbetween, see revision 42028.

So I guess this can be closed.

--

Comment By: Tim Peters (tim_one)
Date: 2006-01-17 21:53

Message:
Logged In: YES 
user_id=31435

No, it's certainly not OK for range(1.0) to raise either
DeprecationWarning or TypeError depending on what __name__
happens to be.  But I may not understand what you mean. 
This is a screen scrape from current SVN trunk, on Windows:

>>> __name__ = None; range(1.0)
None:1: DeprecationWarning: integer argument expected, got float
[0]

I don't see TypeError there, so I'm not sure what

"""
In current SVN heads, range(1.0) gives DeprecationWarning and 
__name__=None; range(1.0) gives TypeError.
"""

means.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:28

Message:
Logged In: YES 
user_id=1188172

In current SVN heads, range(1.0) gives DeprecationWarning and 
__name__=None; range(1.0) gives TypeError.

Is this okay?

--

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:51

Message:
Logged In: YES 
user_id=31435

I'm listening, but with half of part of one ear.  Have to agree 
convertsimple() was wrong in these cases, but can't make 
time for more than that.  Reassigned to Jeremy, partly at 
random (his is one of the names that shows up as a recent 
getargs.c changer).

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-12 14:09

Message:
Logged In: YES 
user_id=6656

Is anyone listening?

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

--

[ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme

[SourceForge.net]

Bugs item #754016, was opened at 2003-06-13 15:15
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Krüger (kruegi)
>Assigned to: Georg Brandl (gbrandl)
Summary: urlparse goes wrong with IP:port without scheme

Initial Comment:
urlparse doesnt work if IP and port are given without 
scheme:

>>> urlparse.urlparse('1.2.3.4:80','http')
('1.2.3.4', '', '80', '', '', '')

should be:

>>> urlparse.urlparse('1.2.3.4:80','http')
('http', '1.2.3.4', '80', '', '', '')

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-25 13:22

Message:
Logged In: YES 
user_id=1188172

Will look into it. Should be easy to fix.

--

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 21:55

Message:
Logged In: YES 
user_id=752496

The problem is still present in Py2.3.4.

IMO, it should support dirs without the "http://"; or raise
an error if it's not present (never fail silently!).

--

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 04:18

Message:
Logged In: YES 
user_id=589306

Ok, I researched this a bit, and the situation isn't as
simple as it first appears. The RFC that urlparse tries to
follow is at http://www.faqs.org/rfcs/rfc1808.html and
notice specifically sections 2.1 and 2.2.

It seems to me that the source code follows rfc1808
religiously, and in that sense it does the correct thing.
According to the RFC, the netloc should begin with a '//',
and since your example didn't include one then it technical
was an invalid URL. Here is another example where it seems
Python fails to do the right thing:

>>> urlparse.urlparse('python.org')
('', '', 'python.org', '', '', '')
>>> urlparse.urlparse('python.org', 'http')
('http', '', 'python.org', '', '', '')

Note that it is putting 'python.org' as the path and not the
netloc. So the problem isn't limited to just when you use a
scheme parameter and/or a port number. Now if we put '//' at
the beginning, we get:

>>> urlparse.urlparse('//python.org')
('', 'python.org', '', '', '', '')
>>> urlparse.urlparse('//python.org', 'http')
('http', 'python.org', '', '', '', '')

So here it does the correct thing.

There are two problems though. First, it is common for
browsers and other software to just take a URL without a
scheme and '://' and assume it is http for the user. While
the URL is technically not correct, it is still common
usage. Also, urlparse does take a scheme parameter. It seems
as though this parameter should be used with a scheme-less
URL to give it a default one like web browsers do.

So somebody needs to make a decision. Should urlparse follow
the RFC religiously and require '//' in front of netlocs? If
so, I think the documentation should give an example showing
this and showing how to use the 'scheme' parameter. Or
should urlparse use the more commonly used form of a URL
where '//' is omitted when the scheme is omitted? If so,
urlparse.py will need to be changed. Or maybe another
fuction should be added to cover whichever behaviour
urlparse doesn't cover.

In any case, you can temporarily solve your problem by
making sure that URL's without a scheme have '//' at the
front. So your example becomes:

>>> urlparse.urlparse('//1.2.3.4:80', 'http')
('http', '1.2.3.4:80', '', '', '', '')



--

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 02:39

Message:
Logged In: YES 
user_id=589306

Sorry, previous comment got cut off...

urlparse.urlparse takes a url of the format:

:///;?#

And returns a 6-tuple of the format:
(scheme, netloc, path, params, query, fragment).

An example from the library refrence takes:
urlparse('http://www.cwi.nl:80/%7Eguido/Python.html')

And produces:
('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '',
'', '')



Note that there isn't a field for the port number in the
6-tuple. Instead, it is included in the netloc. Urlparse
should handle your example as:

>>> urlparse.urlparse('1.2.3.4:80','http') 
('http', '1.2.3.4:80', '', '', '', '')

Instead, it gives the incorrect output as you indicated.


--

Comment By: Shannon Jones (sjones)
Date: 2003-06-14 02:26

Message:
Logged In: YES 
user_id=589306

urlparse.urlparse takes a url of the format:

:///;?#

And r

[ python-Bugs-729103 ] Cannot retrieve name of super object

[SourceForge.net]

Bugs item #729103, was opened at 2003-04-28 18:47
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&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: Type/class unification
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Michele Simionato (michele_s)
>Assigned to: Georg Brandl (gbrandl)
Summary: Cannot retrieve name of super object

Initial Comment:
I see that in Python 2.3b1 many problems of super
have been fixed, but this one is still there:
I cannot retrieve the __name__ of a super object.
This generates problems with pydoc, for instance:

>>> class C(B):
... sup=super(B)
>>> help(C)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.3/site.py", line 293, in
__call__
return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python2.3/pydoc.py", line 1539,
in __call__
self.help(request)
  File "/usr/local/lib/python2.3/pydoc.py", line 1575,
in help
else: doc(request, 'Help on %s:')
  File "/usr/local/lib/python2.3/pydoc.py", line 1368,
in doc
pager(title % desc + '\n\n' + text.document(object,
name))
  File "/usr/local/lib/python2.3/pydoc.py", line 279,
in document
if inspect.isclass(object): return
self.docclass(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1122,
in docclass
lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1057,
in spill
name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 280,
in document
if inspect.isroutine(object): return
self.docroutine(*args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1145,
in docroutine
realname = object.__name__
AttributeError: 'super' object has no attribute
'__name__'

P.S. I seem to remember I already submitted this
bug (or feature request, as you wish ;) but I don't
find it in bugtracker and I had no feedback; maybe
it wasn't sent at all due to some connection problem.
If not, please accept my apologies.

Michele Simionato

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-10-01 16:34

Message:
Logged In: YES 
user_id=1188172

Fixed in Lib/pydoc.py r1.107, 1.100.2.5.

--

Comment By: Brett Cannon (bcannon)
Date: 2003-08-28 00:18

Message:
Logged In: YES 
user_id=357491

The patch was applied.  It's possible one of the subsequent 
patches broke it.

Opening patch again.

--

Comment By: Michele Simionato (michele_s)
Date: 2003-08-19 00:23

Message:
Logged In: YES 
user_id=583457

I've just checked today with Python 2.3 (pydoc
revision 1.86):

class B(object):
pass

class C(B):
sup=super(B)

help(C)

still gives the same error!

What happened? Did you forgot to add the patch to 
the standard distribution? The bug is not close!


--

Comment By: Brett Cannon (bcannon)
Date: 2003-06-11 23:39

Message:
Logged In: YES 
user_id=357491

Patched pydoc (revision 1.84) to try an object as "other" if what 
inspect identifies it as does not work based on its assumptions.

--

Comment By: Brett Cannon (bcannon)
Date: 2003-06-10 23:44

Message:
Logged In: YES 
user_id=357491

The issue is inspect.isroutine is saying that the instance is a 
callable object since it is also a non-data descriptor.

--

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

[ python-Bugs-850238 ] unclear documentation/missing command?

[SourceForge.net]

Bugs item #850238, was opened at 2003-11-27 13:11
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andreas Kostyrka (yacc143)
>Assigned to: Georg Brandl (gbrandl)
Summary: unclear documentation/missing command?

Initial Comment:
Hi!

The documentation of \declaremodule
(http://www.python.org/doc/2.3.2/doc/module-markup.html)
misses one important thing:

It only works as such if you use one \section per module.
(I had some fun LaTeX debugging to find it)

It should also be noted, that perhaps an extra command
to call [EMAIL PROTECTED], something like \endmodule, this way the
author could specify which part of the file pertains to
certain module.

Alternativly, perhaps \declaremodule should flush out
any module info that is already entered?

Andreas

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-18 08:05

Message:
Logged In: YES 
user_id=1188172

Added a remark that each module should be documented in its
own \section.

Doc/doc/doc.tex r1.94, 1.90.2.3.

--

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

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

[SourceForge.net]

Bugs item #869197, was opened at 2004-01-02 09:38
Message generated for change (Settings changed) made by gbrandl
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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Paul Jarc (prjsf)
>Assigned to: Georg Brandl (gbrandl)
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: Georg Brandl (birkenfeld)
Date: 2005-11-22 19:31

Message:
Logged In: YES 
user_id=1188172

Committed in revs 41514 and 41515 (2.4).

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-11-13 10:16

Message:
Logged In: YES 
user_id=21627

The patch looks fine, please apply. Please remove the unused
variable check, though.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-11-11 08:44

Message:
Logged In: YES 
user_id=1188172

Adding enhanced patch.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-10-02 08: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: Georg Brandl (birkenfeld)
Date: 2005-09-29 20: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-Feature Requests-1216944 ] Add Error Code Dictionary to urllib2

[SourceForge.net]

Feature Requests item #1216944, was opened at 2005-06-08 09:45
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1216944&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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Mike Foord (mjfoord)
>Assigned to: Georg Brandl (gbrandl)
Summary: Add Error Code Dictionary to urllib2

Initial Comment:
In order to properly handle 'HTTPError's from 
urllib2.urlopen you need to map error codes to an error 
message.

I suggest the addition of the following dictionary to do 
that  :

# Table mapping response codes to messages; 
entries have the
# form {code: (shortmessage, longmessage)}.
httpresponses = {
100: ('Continue', 'Request received, please 
continue'),
101: ('Switching Protocols',
  'Switching to new protocol; obey Upgrade 
header'),

200: ('OK', 'Request fulfilled, document follows'),
201: ('Created', 'Document created, URL follows'),
202: ('Accepted',
  'Request accepted, processing continues off-
line'),
203: ('Non-Authoritative Information', 'Request 
fulfilled from cache'),
204: ('No response', 'Request fulfilled, nothing 
follows'),
205: ('Reset Content', 'Clear input form for further 
input.'),
206: ('Partial Content', 'Partial content follows.'),

300: ('Multiple Choices',
  'Object has several resources -- see URI list'),
301: ('Moved Permanently', 'Object moved 
permanently -- see URI list'),
302: ('Found', 'Object moved temporarily -- see URI 
list'),
303: ('See Other', 'Object moved -- see Method 
and URL list'),
304: ('Not modified',
  'Document has not changed since given time'),
305: ('Use Proxy',
  'You must use proxy specified in Location to 
access this '
  'resource.'),
307: ('Temporary Redirect',
  'Object moved temporarily -- see URI list'),

400: ('Bad request',
  'Bad request syntax or unsupported method'),
401: ('Unauthorized',
  'No permission -- see authorization schemes'),
402: ('Payment required',
  'No payment -- see charging schemes'),
403: ('Forbidden',
  'Request forbidden -- authorization will not 
help'),
404: ('Not Found', 'Nothing matches the given URI'),
405: ('Method Not Allowed',
  'Specified method is invalid for this server.'),
406: ('Not Acceptable', 'URI not available in 
preferred format.'),
407: ('Proxy Authentication Required', 'You must 
authenticate with '
  'this proxy before proceeding.'),
408: ('Request Time-out', 'Request timed out; try 
again later.'),
409: ('Conflict', 'Request conflict.'),
410: ('Gone',
  'URI no longer exists and has been 
permanently removed.'),
411: ('Length Required', 'Client must specify 
Content-Length.'),
412: ('Precondition Failed', 'Precondition in 
headers is false.'),
413: ('Request Entity Too Large', 'Entity is too 
large.'),
414: ('Request-URI Too Long', 'URI is too long.'),
415: ('Unsupported Media Type', 'Entity body in 
unsupported format.'),
416: ('Requested Range Not Satisfiable',
  'Cannot satisfy request range.'),
417: ('Expectation Failed',
  'Expect condition could not be satisfied.'),

500: ('Internal error', 'Server got itself in trouble'),
501: ('Not Implemented',
  'Server does not support this operation'),
502: ('Bad Gateway', 'Invalid responses from 
another server/proxy.'),
503: ('Service temporarily overloaded',
  'The server cannot process the request due to 
a high load'),
504: ('Gateway timeout',
  'The gateway server did not receive a timely 
response'),
505: ('HTTP Version not supported', 'Cannot fulfill 
request.'),
}

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-14 06:41

Message:
Logged In: YES 
user_id=1188172

Okay. Checked in (without the second field) as
* Lib/urllib2.py r1.83
* Lib/test/test_urllib2.py r1.20
* Doc/lib/liburllib2.tex r1.23
* Misc/NEWS r1.1314

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-13 22:24

Message:
Logged In: YES 
user_id=80475

Reinfeld, you are welcome to put this in.

Pay attention to the little details.  Look-up the http
protocol spec and use the exact spelling and exact
upper/lower letter case.  

Only include the second field 

[ python-Bugs-728515 ] mmap\'s resize method resizes the file in win32 but not unix

[SourceForge.net]

Bugs item #728515, was opened at 2003-04-27 17:44
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&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: Extension Modules
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
>Assigned to: Georg Brandl (gbrandl)
>Summary: mmap\'s resize method resizes the file in win32 but not unix

Initial Comment:
In the resize method under win32 you have something
like this:

/* Move to the desired EOF position */
SetFilePointer (self->file_handle,
new_size, NULL, FILE_BEGIN);
/* Change the size of the file */
SetEndOfFile (self->file_handle);

Which resizes the file

Under Unix you need to call 

   ftruncate(self->fileno, new_size)

before calling remap() to make it do the same thing.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 07:19

Message:
Logged In: YES 
user_id=1188172

Okay, committed as
Modules/mmapmodule.c; 2.50; 2.48.4.1
Lib/test/test_mmap.py; 1.33; 1.30.18.1
Doc/lib/libmmap.tex; 1.12; 1.9.4.2


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 20:50

Message:
Logged In: YES 
user_id=1188172

Attaching patch which duplicates the file handle under UNIX
too (btw, the size() method was broken too), mimics Windows
behaviour with resize(), adds a testcase for this and
clarifies the docs.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-03 20:12

Message:
Logged In: YES 
user_id=1188172

This is not trivial since the filehandle can be closed at
the time the ftruncate() would be necessary.

The Windows specific code duplicates the filehandle upon
mmap creation, perhaps the UNIX code should do this too?
Then, the ftruncate call can be inserted.

--

Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 23:51

Message:
Logged In: YES 
user_id=752496

Reopened as posted that still is a bug.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-30 23:32

Message:
Logged In: YES 
user_id=341410

The problem still persists in Python 2.3 and 2.4.  A quick
read of mmapmodule.c shows that ftruncate() is not being
called within the non-windows portion of mmap_resize_method().

--

Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 18:59

Message:
Logged In: YES 
user_id=752496

Deprecated. Reopen only if still happens in 2.3 or newer. 

.Facundo

--

Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 17:55

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.Facundo

--

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 12:36

Message:
Logged In: YES 
user_id=21627

Would you like to contribute a patch? Please make sure to
include changes to the documentation and test suite.

--

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

[ python-Bugs-735248 ] urllib2 parse_http_list wrong return

[SourceForge.net]

Bugs item #735248, was opened at 2003-05-09 14:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=735248&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: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Georg Brandl (gbrandl)
Summary: urllib2 parse_http_list wrong return

Initial Comment:
parse_http_list should split a string on commas, unless 
the commas are within a quoted-string.  (It allows only 
the "" quote, and not the single-quote, but this seems to 
follow the RFC.)

If there are not quoted-strings, it repeats the first tokens 
as part of subsequent tokens.

parse_http_list ('a,b') => ['a','a,b']
It should return ['a','b']

parse_http_list ('a,b,c') => ['a','a,b','a,b,c']
It should return ['a','b','c']


Patch:  On (cvs version) line 882, when no quote is found 
and inquote is false, reset the start position to after the 
comma.

if q == -1:
if inquote:
raise ValueError, "unbalanced quotes"
else:
list.append(s[start:i+c])
i = i + c + 1
start = i#New line
continue



--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 22:21

Message:
Logged In: YES 
user_id=1188172

Fixed the algorithm in Lib/urllib2.py r1.86, 1.77.2.3
Added testcase in Lib/test/test_urllib2.py r1.22, 1.19.2.1

--

Comment By: John J Lee (jjlee)
Date: 2003-11-09 23:53

Message:
Logged In: YES 
user_id=261020

This function doesn't deal with quoting of characters inside 
quoted-strings, either.  In particular, it doesn't deal with \", \\, 
and \, (see RFC 2616, section 2.2, quoted-pair). 

--

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

[ python-Bugs-810887 ] os.stat returning a time = -1

[SourceForge.net]

Bugs item #810887, was opened at 2003-09-22 23:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810887&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.2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat returning a time = -1

Initial Comment:
(WIN32)  copystat's call to os.stat sometimes returns a
time
value = -1, on which the following call to os.utime
bombs.  
A temporary work-around is attached.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:24

Message:
Logged In: YES 
user_id=849994

Closing as the OP didn't upload his patch.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-23 11:01

Message:
Logged In: YES 
user_id=29957

There's no file attached! You have to upload the file and
check the  little box.


--

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

[ python-Bugs-758504 ] test_sax fails on python 2.2.3 & patch for regrtest.py

[SourceForge.net]

Bugs item #758504, was opened at 2003-06-21 18:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758504&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.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: PieterB (pieterb)
Assigned to: Martin v. Löwis (loewis)
Summary: test_sax fails on python 2.2.3 & patch for regrtest.py

Initial Comment:
Hi,

1) testing using the FreeBSD ports version of Python 
2.2.3 fails (both on FreeBSD 5 and FreeBSD 4.8). The 
test test_sax.py fails, because test_sax seems to 
require expat2 (?), which isn't available by default on 
FreeBSD).

2) I've also patched regrtest.py so that it works on 
FreeBSD 4/5
([EMAIL PROTECTED] tested it on FreeBSD4.8), can somebody
apply the patches from regrtest.py to CVS?
Source: http://www.gewis.nl/~pieterb/python/bugs-
2.2.3/

In detail:

1) testing using the FreeBSD ports version of Python 
2.2.3 failed
==


Using Python 2.2.3 from recent FreeBSD ports
"cd /usr/ports/lang/python ; make ; cd work/Python-
2.2.3 ; make test"
gives:

174 tests OK.
1 test failed:
test_sax
18 tests skipped:
test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
test_unicode_file test_winreg test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on freebsd5.
*** Error code 1

Stop in /usr/ports/lang/python/work/Python-2.2.3.



cd /usr/ports/lang/python/work/Python-2.2.3/Lib/test
../../python test_sax.py
gives:
test_support.TestFailed: 3 of 40 tests failed

...
Expected:
[('start', ('http://xml.python.org/1', 'abc'), 'abc'),
 ('start', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/2', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'ghi'), 'ghi'),
 ('end', ('http://xml.python.org/1', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/1', u'abc'), None),
 ('start', (u'http://xml.python.org/2', u'def'), None),
 ('end', (u'http://xml.python.org/2', u'def'), None),
 ('start', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'ghi'), None),
 ('end', (u'http://xml.python.org/1', u'abc'), None)]
Failed test_expat_nsdecl_pair_diff
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'foo:abc'),
 ('start', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('end', ('http://xml.python.org/', 'def'), 'foo:def'),
 ('start', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'ghi'), 'foo:ghi'),
 ('end', ('http://xml.python.org/', 'abc'), 'foo:abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('start', (u'http://xml.python.org/', u'def'), None),
 ('end', (u'http://xml.python.org/', u'def'), None),
 ('start', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'ghi'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_pair_same
Expected:
[('start', ('http://xml.python.org/', 'abc'), 'abc'),
 ('end', ('http://xml.python.org/', 'abc'), 'abc')]
Received:
[('start', (u'http://xml.python.org/', u'abc'), None),
 ('end', (u'http://xml.python.org/', u'abc'), None)]
Failed test_expat_nsdecl_single

I managed to fixed this by patching test_sax.py,
see http://gewis.nl/~pieterb/python/bugs-2.2.3/

2) i've patched regrtest.py so that it works on FreeBSD 
4/5
==
=
This make it possible to run 'make test' on Python.
It will give the following output:
  175 tests OK.
  18 tests skipped:
test_al test_cd test_cl test_curses 
test_email_codecs test_gdbm
test_gl test_imgfile test_linuxaudiodev test_locale 
test_nis
test_pyexpat test_socket_ssl test_socketserver 
test_sunaudiodev
test_unicode_file test_winreg test_winsound
  Those skips are all expected on freebsd5.

Can anybody confirm that it's ok to skip those tests.  
Can anybody
download the patched version of regrtest.py from the 
URL above check
it into Python CVS?

Thanks to [EMAIL PROTECTED] for testing it on FreeBSD4.8
Thanks to [EMAIL PROTECTED] and others at IRC:#python for their 
help.

PieterB

--
http://zwiki.org/PieterB





--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:27

Message:
Logged In: YES 
user_id=849994

Expectations for FreeBSD 5 have been added to regrtest.py.

[ python-Bugs-820953 ] dbm Error

[SourceForge.net]

Bugs item #820953, was opened at 2003-10-09 23:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&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: Extension Modules
Group: Python 2.2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Jim Gifford (giffordj)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbm Error

Initial Comment:
Receive the following error during make install of python 
2.3.2. Any suggestions or is it safe to ignore.

building 'dbm' extension
gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx -
O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict-
aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python-
2.3.2/./Include -I/usr/local/include -I/usr/src/Python-
2.3.2/Include -I/usr/src/Python-2.3.2 -
c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o 
build/temp.linux-i686-2.3/dbmmodule.o
gcc -pthread -shared build/temp.linux-i686-
2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-
2.3/dbm.so
*** WARNING: renaming "dbm" since importing it failed: 
build/lib.linux-i686-2.3/dbm.so: undefined symbol: 
dbm_firstkey
running build_scripts


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:30

Message:
Logged In: YES 
user_id=849994

Do you still have problems with 2.4?

--

Comment By: Jim Gifford (giffordj)
Date: 2003-10-12 07:42

Message:
Logged In: YES 
user_id=492775

Upon further research, when this error occurs installation 
does continue, but libpython2.3.a is never created.

--

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

[ python-Bugs-856841 ] a exception ocurrs when compiling a Python file

[SourceForge.net]

Bugs item #856841, was opened at 2003-12-09 12:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&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.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Pablo Yabo (pablo_yabo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a exception ocurrs when compiling a Python file

Initial Comment:
a exception ocurrs when compiling some big python files 
(more than 250kb) using the debug library 
(python22_d.dll).
When using the release library in the release version of 
my application the files compile succesfully. 
Attached is the stack trace.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 15:39

Message:
Logged In: YES 
user_id=849994

This is likely to be resolved with the new AST compiler in 2.5.

If not, please open another bug report then.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-12-16 15:37

Message:
Logged In: YES 
user_id=593130

If, by 'exception', PY indeed means a system crash rather 
than a Python exception, then I agree that more graceful 
termination would be desireable.  However, I believe someone 
once pointed out on Py-Dev list that memory failures may 
make interpreter operation, even to produce a Python stack 
trace, impossible.  In any case, the details of system 
software and hardware, including memory, needed to even 
discuss this, are still missing.

--

Comment By: Jack Jansen (jackjansen)
Date: 2003-12-15 10:04

Message:
Logged In: YES 
user_id=45365

I agree with the original poster that this is a bug. While it may not 
be fixable (and definitely not in the general case) you should get a 
decent error message from Python (at the very least a 
MemoryError), not a crash of the interpreter.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-12-15 04:26

Message:
Logged In: YES 
user_id=593130

I do not believe this is a compiler bug.  While compiler input 
may by theoretically unbounded, all practical compilers have 
practical limitations that often depend, in part, on the 
amount of memory on your particular system.  This is one 
reason for import and include mechanisms.

As I understand the stack trace, the exception occured 
during an attempt to reallocate memory (ie, move an object 
to a larger block).  (Including Python's exception trace would 
make this clearer).  I presume debug mode uses more memory 
so you hit the limit sooner with that mode.

Your solutions are to either 1) add more memory to your 
computer (should probably work) or try on a system with 
more memory or 2) break your source into more modules 
(certain to work if the problem is, indeed, simply running out 
of memory).  250K is not merely big but huge.  The largest 
file in the standard lib is under 100K and the median is around 
10K.

Unless you have more reason to think this a bug, please 
withdraw or close.


--

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