[ python-Bugs-1163367 ] correct/clarify documentation for super

2006-07-31 Thread SourceForge.net 
Bugs item #1163367, was opened at 2005-03-14 18:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 03:01

Message:
Logged In: YES 
user_id=3066

Thanks Steven; that helps a lot!

I've attached a revised version of my patch that describes
both 2-arg forms; I'll see about refining it further after
I've had a bit of sleep, and time to play with the 1-arg form.

--

Comment By: Steven Bethard (bediviere)
Date: 2006-07-31 01:02

Message:
Logged In: YES 
user_id=945502

The two-arg type form is intended for use with classmethods,
e.g.::

>>> class C(object):
... @classmethod
... def f(cls):
... print 'C.f'
... 
>>> class D(C):
... @classmethod
... def f(cls):
... super(D, cls).f()
... print 'D.f'
... 
>>> D.f()
C.f
D.f

I do make use of this occasionally, so I do think it should
be documented.

The one-arg form is intended to be used as a class attribute::

>>> class C(object):
... def f(self):
... print 'C.f'
... 
>>> class D(C):
...  def f(self):
...  self.super.f()
...  print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
C.f
D.f

I don't know that we should really be advertising this
one-arg form though.  It requires modifying a class outside
the definition or using some metaclass hackery to be usable.
 And it's misleading because it won't work, for example,
with classmethods:

>>> class C(object):
... @classmethod
... def f(cls):
... print 'C.f'
... 
>>> class D(C):
... @classmethod
... def f(cls):
... cls.super.f()
... print 'D.f'
... 
>>> D.super = super(D)
>>> D().f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 4, in f
AttributeError: 'super' object has no attribute 'f'

That's why I tried to gloss over it lightly.  Personally I'd
prefer that the one-arg form was just deprecated.  It
introduces a lot more problems than it solves.

But if it has to be documented, it should probably say
something like "A super object created with a single
argument produces a descriptor object. This descriptor
object makes the superclass methods available on the object
returned by its __get__ method. The superclass methods are
only available when __get__ is called with an instance (not
a class)."


--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-07-31 00:29

Message:
Logged In: YES 
user

[ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs

2006-07-31 Thread SourceForge.net 
Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Comment added) made by gdm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in 
main()
.
.
  File "./setup.py", line 1088, in addMacExtension
raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===
--- setup.py(revision 50687)
+++ setup.py(working copy)
@@ -1101,7 +1101,7 @@
 carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
'extra_link_args':
['-framework', 'Carbon'],
   }
-CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
'OSATerminology', 'icglue',
# All these are in subdirs
'_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



--

>Comment By: gideon may (gdm)
Date: 2006-07-31 12:14

Message:
Logged In: YES 
user_id=117359

The rename works for me. I've been able to compile with and without
the --enable-framework configure option and both versions can import
and use MacOS correctly.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

--

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

[ python-Bugs-1530448 ] ctypes build fails on Solaris 10

2006-07-31 Thread SourceForge.net 
Bugs item #1530448, was opened at 2006-07-28 17:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: ctypes build fails on Solaris 10

Initial Comment:
Thomas,

I tried to build Python from cvs (svn rev 50905) on
Solaris 10 today.
Compiler was gcc 3.4.  I got a text relocation error
when linking
ctypes.so:

/opt/app/g++lib6/gcc-3.4/bin/gcc -shared
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
-L/usr/local/lib -o
build/lib.solaris-2.10-i86pc-2.5/_ctypes.so
Text relocation remains referenced
against symbol  offset  in file
ffi_closure_SYSV_inner  0x8e   
build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status

I tried configuring both with and without the
--with-system-ffi flag.
The error was the same in both cases.

If you need more information, let me know.

Skip


--

>Comment By: Thomas Heller (theller)
Date: 2006-07-31 12:54

Message:
Logged In: YES 
user_id=11105

Skip, do you have *any* idea what might be wrong, or could
you even come up with a patch?

--

Comment By: Skip Montanaro (montanaro)
Date: 2006-07-29 00:03

Message:
Logged In: YES 
user_id=44345

Yeah, you'd definitely need -fPIC on any brand of Solaris.  That test might be 
changed to

plat = get_platform()
if plat in (... buncha platforms ...) or "solaris" in plat:
os.environ["CFLAGS"] = "-fPIC"

That doesn't seem to be what's happening in this case though.  I rm'd the .o 
files in .../Modules/_ctypes and tried again.  The compile commands *do* 
have -fPIC on them.  I don't think it's required on the link line.

S


--

Comment By: Thomas Heller (theller)
Date: 2006-07-28 18:19

Message:
Logged In: YES 
user_id=11105

Skip,

This looks *somewhat* like the problems reported in bugs
1529269 and 1528620 (although they have a sparc, and you
seem to have x86 solaris).

Hm, in the standalone ctypes setup script, I find this code
snippet:

if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]:
os.environ["CFLAGS"] = "-fPIC"

Can it be that -fPIC must be used, but is not specified?

It is also funny that the solaris buildbot does NOT seem to
have a problem.

--

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

[ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol

2006-07-31 Thread SourceForge.net 
Bugs item #1531662, was opened at 2006-07-31 12:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: gideon may (gdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

--

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

[ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol

2006-07-31 Thread SourceForge.net 
Bugs item #1531662, was opened at 2006-07-31 10:58
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: gideon may (gdm)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

--

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

[ python-Bugs-1531775 ] HTTPSConnection request hangs

2006-07-31 Thread SourceForge.net 
Bugs item #1531775, was opened at 2006-07-31 17:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531775&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Noam Taich (grolich)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPSConnection request hangs

Initial Comment:
with python 2.3 and above there is a problem with
HTTPSConnection that comes to life in the following code:

conn = HTTPSConnection(server,port)
conn.connect()
conn.request('POST', '/', data, headers)

This works fine, unless the remote host closes
unexpectedly (unexpectedly for the client. say, reboot
-fn or reset button)

sometimes (not always) when that happens, python gets
stuck on the conn.request command, it never returns or
raises an eyebrow (or an exception...) even after the
remote host is back online. 

problem only happens once every many such occurences

the remote host is running apache (which is really used
a proxy to a python http server on the same remote
machine).

--

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

[ python-Bugs-1514540 ] String Methods 2.3.6.1 not in TOC

2006-07-31 Thread SourceForge.net 
Bugs item #1514540, was opened at 2006-06-29 14:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514540&group_id=5470

Please note that this 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: Terry J. Reedy (tjreedy)
>Assigned to: A.M. Kuchling (akuchling)
Summary: String Methods 2.3.6.1 not in TOC

Initial Comment:
Quoting from c.l.p thread Python Docs Bug:
"One long-standing irritation I have with the table 
of contents for the Python Library Reference 
, is that 
there is one very important section, "String Methods" 
, 
which does not appear there. That's because it is 
section 2.3.6.1, and the table of contents 
only goes to 3 levels."

I am third to agree.  To not change rule, perhaps 
this section could be lifted to third level.  It 
really is one that people need to refer back to.


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:11

Message:
Logged In: YES 
user_id=11375

For 2.5, I've moved the standard types to be a chapter of
their own instead of a section.  This should fix the problem.


--

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

[ python-Bugs-984952 ] PEP 307 pickle extensions not documented

2006-07-31 Thread SourceForge.net 
Bugs item #984952, was opened at 2004-07-04 11:45
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470

Please note that this 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: Greg Chapman (glchapman)
>Assigned to: A.M. Kuchling (akuchling)
Summary: PEP 307 pickle extensions not documented

Initial Comment:
>From a quick perusal of the developer documentation
(from www.python.org), it appears that PEP 307 has not
yet been integrated into the standard documentation.

--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:17

Message:
Logged In: YES 
user_id=11375

Presumably this bug can now be closed.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 12:25

Message:
Logged In: YES 
user_id=11375

I've included a bunch of material from PEP 307 in the CVS HEAD version 
of the pickle docs. 

I haven't tried to include all the material on old-style classes using 
protocols 0,1.  The details are lengthy; someone who knows 
more about the pickle module should decide if they're important enough
to be in the docs or not.

--

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

[ python-Bugs-848556 ] 4.2.6 (re) Examples: float regexp exponential on failure

2006-07-31 Thread SourceForge.net 
Bugs item #848556, was opened at 2003-11-24 15:01
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848556&group_id=5470

Please note that this 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: Lukasz Pankowski (lupan)
>Assigned to: A.M. Kuchling (akuchling)
Summary: 4.2.6 (re) Examples: float regexp exponential on failure

Initial Comment:
When using given regexp for floats

[-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)?

'0.5' will match both alternatives on failure, which
makes exponential number of matches on failure if
matching multiple float numbers  '0.5 0.5 0.5' using
one regexp which fail at the end (attached test script).

If replaced with slightly less verbose (without '\d*'
after '|'):

[-+]?(\d+(\.\d*)?|\.\d+)([eE][-+]?\d+)?

'0.5' fails on the second branch and the exponential
effect does not occur.


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:22

Message:
Logged In: YES 
user_id=11375

The suggested change seems reasonable, so I've applied it. 
Thanks!


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 02:43

Message:
Logged In: YES 
user_id=33168

Gustavo, are you still interested in re issues?  This is
actually a doc issue (I think it's only a doc issue).  Any
comments?  I can make a change if you want me to, just let
me know what to do.

--

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

[ python-Bugs-779976 ] docs missing 'trace' module

2006-07-31 Thread SourceForge.net 
Bugs item #779976, was opened at 2003-07-29 22:05
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470

Please note that this 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: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Jeremy Hylton (jhylton)
Summary: docs missing 'trace' module

Initial Comment:
The 'trace' module is new in Python 2.3.  There is no 
mention of it in the module listing at http://www.python.org/
doc/2.3/modindex.html nor is it documented in the 
"undocumented modules" chapter at http://www.python.org/
doc/2.3/lib/undoc.html .

(You would think as one of the coauthors for that module 
that I could be of help, but it's been about 4 years since I 
looked at it.  :)


--

>Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-31 12:33

Message:
Logged In: YES 
user_id=11375

I've updated the scripts/README in preparation for the 2.5b3
release.


--

Comment By: Peter Hansen (phansen)
Date: 2003-12-09 14:19

Message:
Logged In: YES 
user_id=567267

A trivial related note: Tools/Scripts/README.txt still lists 
trace.py as though it were still there and not in Lib instead.

--

Comment By: Michael Hudson (mwh)
Date: 2003-10-16 09:17

Message:
Logged In: YES 
user_id=6656



Armin and I were talking about factoring out the
co_lnotab-frobbing code and were being hampered by not
knowing what the code was trying to do...

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-09 17:00

Message:
Logged In: YES 
user_id=3066

Jeremy made this a module, so he's volunteered to write the
LaTeX docs.

--

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

[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails

2006-07-31 Thread SourceForge.net 
Bugs item #1531862, was opened at 2006-07-31 11:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails

Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.

One valid output is to send it to sys.stdout (fileno == 1)

The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).

Compare:
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'])"

versus
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"

or even
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=1)"

The first one prints 'hello' as expected.

The latter two give an error:
echo: write error: Bad file descriptor

Attached is a possible patch to subprocess.py

--

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

[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails

2006-07-31 Thread SourceForge.net 
Bugs item #1531862, was opened at 2006-07-31 11:53
Message generated for change (Settings changed) made by jfmeinel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails

Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.

One valid output is to send it to sys.stdout (fileno == 1)

The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).

Compare:
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'])"

versus
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"

or even
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=1)"

The first one prints 'hello' as expected.

The latter two give an error:
echo: write error: Bad file descriptor

Attached is a possible patch to subprocess.py

--

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

[ python-Bugs-1525447 ] Build fails on OS X with case sensitive fs

2006-07-31 Thread SourceForge.net 
Bugs item #1525447, was opened at 2006-07-19 19:24
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525447&group_id=5470

Please note that this 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: Closed
Resolution: Fixed
Priority: 6
Submitted By: gideon may (gdm)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Build fails on OS X with case sensitive fs

Initial Comment:
When compiling python from svn on a Mac OS X with a 
case sensitive file system I get the following build
error:

running build
running build_ext
db.h: found (4, 3) in /opt/local/include/db4
db lib: using (4, 3) db-4.3
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
Traceback (most recent call last):
  File "./setup.py", line 1507, in 
main()
.
.
  File "./setup.py", line 1088, in addMacExtension
raise RuntimeError("%s not found" % name)
RuntimeError: MacOS not found
make: *** [sharedmods] Error 1




It can be fixed by either renaming the file:
  Mac/Modules/macosmodule.c 
to
  Mac/Modules/MacOSmodule.c 

or applying the following patch :
Index: setup.py
===
--- setup.py(revision 50687)
+++ setup.py(working copy)
@@ -1101,7 +1101,7 @@
 carbon_kwds = {'extra_compile_args':
carbon_extra_compile_args,
'extra_link_args':
['-framework', 'Carbon'],
   }
-CARBON_EXTS = ['ColorPicker', 'gestalt',
'MacOS', 'Nav',
+CARBON_EXTS = ['ColorPicker', 'gestalt',
'macos', 'Nav',
'OSATerminology', 'icglue',
# All these are in subdirs
'_AE', '_AH', '_App',
'_CarbonEvt', '_Cm', '_Ctl',


Cheers,

Gideon



--

Comment By: gideon may (gdm)
Date: 2006-07-31 12:14

Message:
Logged In: YES 
user_id=117359

The rename works for me. I've been able to compile with and without
the --enable-framework configure option and both versions can import
and use MacOS correctly.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-25 21:21

Message:
Logged In: YES 
user_id=580910

I've implemented the rename I suggested earlier in revision 50832.

Could you please confirm that this does actually solve your problem?

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 20:11

Message:
Logged In: YES 
user_id=580910

Could you please test if renaming Mac/Modules/macosmodule.c to Mac/
Modules/MacOS.c solves your problem?  With that rename the build still works 
for me, but I don't have a case-sensitive filesystem.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-23 11:31

Message:
Logged In: YES 
user_id=580910

The patch is incorrect, as this would rename user visible name of the python 
extension ('import MacOS' would stop working). 

The rename would be correct.

--

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

[ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol

2006-07-31 Thread SourceForge.net 
Bugs item #1531662, was opened at 2006-07-31 12:58
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: gideon may (gdm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:43

Message:
Logged In: YES 
user_id=580910

Did you build a unix or framework install?

--

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

[ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports

2006-07-31 Thread SourceForge.net 
Bugs item #1531963, was opened at 2006-07-31 19:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470

Please note that this 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: hakker.de (hakker_de)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer.TCPServer returns different ports

Initial Comment:
Providing 0 as a port in __init__ of 
SocketServer.TCPServer leads to different values for 
port in server_address and socket.getsockname().

Example:
import SocketServer
s = SocketServer.TCPServer(("0.0.0.0", 0), Handler)
s.server_address
-> ('0.0.0.0', 0)
s.socket.getsockname()
-> ('0.0.0.0', 39129)

s.server_address should also contain 39129 as the 
port number for the free port found.


--

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

[ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol

2006-07-31 Thread SourceForge.net 
Bugs item #1531662, was opened at 2006-07-31 12:58
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: gideon may (gdm)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Build fails on MacOSX with missing symbol

Initial Comment:
When compiling the latest svn version on MacOS, the build
fails with the following error in libpython2.5.a:
ld: Undefined symbols:
_init_types
libtool: internal link edit command failed

When I add Modules/_typesmodule.c to Modules/Setup.dist
everything is hunky-dory, but am not sure if this is the correct place 
since python seems to compile ok on Linux without the addition

--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:58

Message:
Logged In: YES 
user_id=580910

I cannot reproduce this with the current head (svnversion says 51008). Did you 
do a clean build? Maybe some junk from a previous build caused problems.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-31 21:43

Message:
Logged In: YES 
user_id=580910

Did you build a unix or framework install?

--

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

[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails

2006-07-31 Thread SourceForge.net 
Bugs item #1531862, was opened at 2006-07-31 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=1531862&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
>Assigned to: Peter Åstrand (astrand)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails

Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.

One valid output is to send it to sys.stdout (fileno == 1)

The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).

Compare:
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'])"

versus
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"

or even
python -c "import subprocess,sys; \
  subprocess.Popen(['echo', 'hello'], stdout=1)"

The first one prints 'hello' as expected.

The latter two give an error:
echo: write error: Bad file descriptor

Attached is a possible patch to subprocess.py

--

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

[ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii

2006-07-31 Thread SourceForge.net 
Bugs item #1501291, was opened at 2006-06-05 16:34
Message generated for change (Comment added) made by unixops1234
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470

Please note that this 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: UnixOps (unixops1234)
Assigned to: Nobody/Anonymous (nobody)
Summary: python/ncurses bug in 2.4.3 with extended ascii

Initial Comment:
There is a problem displaying extended ascii characters
in ncurses through python, which does not exist in
versions prior to 2.4.2. I am running RedHat Enterprise
Linux WS 3 with updated patches, using the system
version of ncurses (ncurses-5.3-9.4 and devel). When
building a vanilla python 2.4.3 from source, printing
extended ascii characters in ncurses fails:

$ cat test.py
import curses

screen = curses.initscr()

screen.addstr("\x80")

screen.getch()
curses.endwin()

$ python test.py
Traceback (most recent call last):hon test.py
File "test.py", line 5, in ?
screen.addstr("\x80")
_curses.error: addstr() returned ERR

This should produce a blank ncurses screen, rather than
the addstr() error. I've been able to confirm that it
works with python 2.4.2 and earlier. 

To ensure that ncurses was able to display the
character, I wrote this test C program: 

$ cat test.c
#include 

int main()
{
initscr();
int rtn = addstr("\x80");
getch(); 
endwin();
printf("The return value was %d.\n",rtn);
return 0;
}

$ gcc test.c -o test -lncurses
$ ./test

This works just fine, so I think the problem lies
somewhere in the python interface to ncurses. Python
can print this character without errors when not using
ncurses. Perhaps ncurses is expecting different
initialization than python is providing.  

I've also tested this on a RedHat WS 4 machine, where
it works just fine. This system is running
ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the
newer release of python has changed something that the
older versions of ncurses are unable to handle.  

Can this be fixed in _cursesmodule.c?

--

>Comment By: UnixOps (unixops1234)
Date: 2006-07-31 16:33

Message:
Logged In: YES 
user_id=1534776

akuchling, thanks. Your suggestion worked. I added

import locale
locale.setlocale(locale.LC_ALL, 'en_US')

to the beginning of my test.py script and it correctly
displayed the funky character.

loewis, what I meant is that the C code correctly printed a
strange character instead of crashing with a curses error
message. 

The panelw patch is not needed after all. The test.py script
also works just fine if I build python against ncurses 5.5
instead of 5.4.

Thank you both for your help with this.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-26 14:39

Message:
Logged In: YES 
user_id=21627

unixops1234, can you please explain what "works just fine"
for the C code means? \x80 is not a meaningful character for
the terminal. On my system (Debian with ncurses 5.5, locale
de_DE.UTF-8, konsole), the program prints something, namely
the characters ~@


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-26 12:45

Message:
Logged In: YES 
user_id=11375

The ncurses 5.5 changelog, currently at
http://www.gnu.org/software/ncurses/ncurses.html, contains
this entry:

  * use setlocale() to query the program's current locale
rather than using getenv(). This supports applications which
rely upon legacy treatment of 8-bit characters when the
locale is not initialized.

So maybe this is a problem in ncurses 5.4 that can be
avoided if your Python script calls 'locale.setlocale("")'.


--

Comment By: UnixOps (unixops1234)
Date: 2006-06-08 14:02

Message:
Logged In: YES 
user_id=1534776

I tried recompiling Python with the patch from bug #1464056
that fixes the panelw linking in _curses_panel.so. It now
properly links with libpanelw instead of libpanel, but the
original problem persists. I still get "_curses.error:
addstr() returned ERR" when running the test code.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-06-08 11:58

Message:
Logged In: YES 
user_id=21627

I doubt it can be fixed in _cursesmodule. Notice that Python
links with ncursesw now, not with ncurses anymore. There is
a bug in 2.4.3 which links, apparently incorrectly, with
panel instead of panelw. Try changing that and see whether
it helps.

--

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

[ python-Bugs-1506951 ] pydoc fails on package in ZIP archive

2006-07-31 Thread SourceForge.net 
Bugs item #1506951, was opened at 2006-06-16 00:07
Message generated for change (Comment added) made by zseil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (christopherdunn)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails on package in ZIP archive

Initial Comment:
I have Foo/__init__.py and Foo/bar.py in a ZIP archive,
test.zip, which is in the PYTHONPATH. 

pydoc works on Foo.bar, but fails on package Foo.

% pydoc Foo
Traceback (most recent call last):
  File "~/bin/pydoc", line 5, in ?
pydoc.cli()
  File "../python-2.4/lib/python2.4/pydoc.py", line
2228, in cli
help.help(arg)
  File "../python-2.4/lib/python2.4/pydoc.py", line
1682, in help
elif request: doc(request, 'Help on %s:')
  File "../python-2.4/lib/python2.4/pydoc.py", line
1468, in doc
pager(title % desc + '\n\n' + text.document(object,
name))
  File "../python-2.4/lib/python2.4/pydoc.py", line
296, in document
if inspect.ismodule(object): return
self.docmodule(*args)
  File "../python-2.4/lib/python2.4/pydoc.py", line
1053, in docmodule
for file in os.listdir(object.__path__[0]):
OSError: [Errno 20] Not a directory: 'test.zip/Foo'


--

Comment By: �iga Seilnacht (zseil)
Date: 2006-08-01 01:49

Message:
Logged In: YES 
user_id=1326842

This is fixed in the 2.5 release.  The details of the
fix are quite involved, so it is unlikely that it will
be backported.
See revision 45510 for details:
http://mail.python.org/pipermail/python-checkins/2006-April/051452.html



--

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

[ python-Bugs-215126 ] Over restricted type checking on eval() function

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

Please note that this 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: Feature Request
Status: Closed
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Armin Rigo (arigo)
Summary: Over restricted type checking on eval() function

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

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

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

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


--

Comment By: Anand Aiyer (aaiyer)
Date: 2006-08-01 06:20

Message:
Logged In: YES 
user_id=1554342

There is a missing PyErr_Clear() in the GetItem at LOAD_NAMES

--

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

Message:
Logged In: YES 
user_id=80475

Made the requested changes, tested, and applied.
Will tackle exec and execfile on another day.

--

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 15:06

Message:
Logged In: YES 
user_id=4771

Patch reviewed:

As eval(expr, mapping) is not accepted but eval(expr, {},
mapping) is, we could have a helpful error message along the
line of
  if (!PyDict_Check(globals)) {
  PyErr_SetString(PyExc_TypeError,
  PyMapping_Check(globals) ? 
  "globals must be a real dict; try eval(expr,
{}, mapping)"
: "globals must be a dict");
  }

LOAD_NAME: you are doing a speed hack here we will bypass a
user-defined __getitem__ on a subclass of dict if the key
actually exists in the dictionary.  In other words your test
with the subclass of dict would fail if the dict aditionally
had another real value for the key 'a'.  Better use
PyDict_CheckExact() in all cases and only call
PyDict_GetItem() if it is true, as this is really cheap. 
Also, no PyErr_Clear() masking arbitrary exceptions please!


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 20:38

Message:
Logged In: YES 
user_id=80475

Are you comfortable doing this in two steps.  Commit the
patch as-is so that eval() works properly and then craft a
separate patch 
to thoroughly implement, test, and document the same thing
for exec and execfile()?

--

Comment By: Armin Rigo (arigo)
Date: 2004-06-29 10:36

Message:
Logged In: YES 
user_id=4771

Doing the type check in exec and execfile() but not in
eval() is not something that seems particularly useful to
me.  Any program can be written as an expression in Python
if you are crazy enough to do that...  So it doesn't offer
any extra security to be more strict in exec than in eval().
 People who really want to do it would have to go through
incredible pain just to work around the type check.

For the implications, I believe it is sufficient (and
necessary) to carefully review all usages of f_locals
throughout the code, and document f_locals as no longer
necessary a dictionary for those extension writers that
would have used this fact.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 08:51

Message:
Logged In: YES 
user_id=80475

Okay, a new patch is ready for second review.

It is essentially, Armin's patch with the following changes:

* leaves the syntax for eval() intact with no automatic
globals=locals trick

* has the faster approach for LOAD_NAME, incorporating your
suggestion for PyDict_CheckExact

* omits the code to enable the same liberties for '.exec'. 
That is beyond the OP's request and well beyond something
whose implications I've thought through.  Am not opposed to
it, but would like it to be left for a separate patch with
thorough unittests.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 18:08

Message:
Logged In: YES 
user_id=80475

Nix, that last comment.  Have examples that call setitem().

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 17:36

Message