[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes

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

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python is dumping core after the test test_ctypes

Initial Comment:


Hi ,

  Iam building Python-2.5 on HPUX Itanium. The 
compilation is done without any error, but while 
testing the same using gmake test it is dumping core 
telling "Segementation Fault" after the test 
test_ctypes. Please help me in resolving the above 
issue.Iam attaching the output of gmake test.

Thanks in advance,



--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

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

Please note that this 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: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: Ulrich Hockenbrink (uhocke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: Ulrich Hockenbrink (uhocke)
>Assigned to: Martin v. Löwis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 14:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 13:16
Message generated for change (Comment added) made by uhocke
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: Ulrich Hockenbrink (uhocke)
Assigned to: Martin v. Löwis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 14:45

Message:
Logged In: YES 
user_id=1627884

Yes it is. 
Under \Python-2.5\PC\VC6 you can find a Visual Studio 6.0
workspace file.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 14:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 13:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1580726 ] Configure script does not work for RHEL 4 x86_64

2006-10-23 Thread SourceForge.net
Bugs item #1580726, was opened at 2006-10-19 18:38
Message generated for change (Comment added) made by spotvt01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Chris (spotvt01)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure script does not work for RHEL 4 x86_64

Initial Comment:
I tryto build python 2.4 with:
./configure --enable-unicode=4 --prefix=/usr
--exec-prefix=/usr

Attached is the config.log file

--

>Comment By: Chris (spotvt01)
Date: 2006-10-23 15:00

Message:
Logged In: YES 
user_id=1624982

OK, thanx for the time/tutelage.

I'll ask you off line about some other difficulties I'm
having with 64 & 32-bit python library locations.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-10-22 14:20

Message:
Logged In: YES 
user_id=21627

It's actually not a bug in the Python configure, but a
limitation of AMD64 (or, rather, the linker/dynamic loader
toolchain).

It complains that some object file of Python wasn't compiled
with -fPIC (position-independent code). This is a problem
only if
a) you are linking a static library into a shared one
(mod_python, in this case), and
b) the object files in the static library weren't compiled
with -fPIC, and
c) the system doesn't support position-dependent code in a
shared library

As you may have guessed by now, it is really c) which I
blame. On all other modern systems, linking non-PIC objects
into a shared library is supported (albeit sometimes with a
performance loss on startup).

So your options are
a) don't build a static libpython, instead, build Python
with --enable-shared. This will give you libpython24.so
which can then be linked "into" mod_python
b) manually add -fPIC to the list of compiler options when
building Python, by editing the Makefile after configure has run
c) find a way to overcome the platform limitation. E.g. on
Solaris, the linker supports an impure-text option which
instructs it to accept relocations in a shared library.

You might wish that the Python build process supported
option b), i.e. automatically adds -fPIC on Linux/AMD64.
IMO, this would be a bad choice, since -fPIC itself usually
causes a performance loss, and isn't needed when we link
libpython24.a into the interpreter (which is an executable,
not a shared library).

Therefore, I'll close this as "won't fix", and recommend to
go with solution a).

--

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:32

Message:
Logged In: YES 
user_id=1624982

I think the important part of the mod_python compile error
is the last part where the linker fails to link in
libpython2.4.a   ... that's why I think it's an error with
the configure file for python.  It says that libpython2.4.a
should be compiled with position-independant-code.  If I
remember correctly, any static library needs to be PIC for a
x86_64 machine ... that's why it seems like an error for python.

/usr/bin/ld:
/usr/lib/python2.4/config/libpython2.4.a(abstract.o):
relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/python2.4/config/libpython2.4.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536


--

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 19:14

Message:
Logged In: YES 
user_id=849994

actually, this is okay, the "pending" status is
automatically set to "open" again when the OP posts an answer.

I can't read anything out of that error log, however,
perhaps Martin can.

--

Comment By: Chris (spotvt01)
Date: 2006-10-19 19:04

Message:
Logged In: YES 
user_id=1624982

wait, I didn't mean to change the status, sory about that.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-19 18:56

Message:
Logged In: YES 
user_id=849994

The unicode build option should be "--enable-unicode=ucs4".
Can you retry with that option?

--

Comment By: Chris (spotvt01)
Date: 2006-10-19 18:55

Message:
Logged In: YES 
user_id=1624982

Ok, so when you add a file, it automatically submits 

Well ... like I was saying..

./configure --enable-unicode=ucs4 --prefix=/usr
--exec-prefix=/usr
make
make altinstall

please see attached config.log for the configuration of python. 

I then go to make mod_pyt

[ python-Bugs-1583060 ] class member inconsistancies

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

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

CodeStart
 

class A(object):
def __init__(self):


self.argsList = []
self.dictArgs = {}
self.ARG1 = ""
self.ARG2 = ""

def multUnnammedArgs(self,
 *argsList):
if not argsList is None:
self.argsList += argsList


def multNAmmedArgument(self,
   **argDict):
if not argDict is None:
for i in argDict.iteritems():
self.dictArgs[i[0]] = i[1]

def mixedArguments(self, 
   ARG1,
   ARG2,
   *argList,
   **argDict):
self.ARG1 = ARG1
self.ARG2 = ARG2

self.multUnnammedArgs(*argList)

self.multNAmmedArgument(**argDict)

def __str__(self):
string = "Object A :"
string += "\n\t\tARG1=" + self.ARG1 
string += "\n\t\tARG2=" + self.ARG2 
string += "\n\tUnnammed Arguments"
for a in self.argsList:
string += "\n\t\t" + a

string += "\n\tNamed Arguments"
for a in self.dictArgs.iteritems():
string += "\n\t\t" + a[0] + "=" + a[1]

return string


if __name__ == '__main__':
obj = A()

obj.multUnnammedArgs("arg1", "arg2", "arg3")
print obj

obj.multNAmmedArgument(TOTO = "toto",
   TITI = "titi",
   TaTa = "tATa")

print obj   
obj.mixedArguments(ARG1="ZeArg1",
   ARG2="ZeArg2",
   TOTO2 = "toto2",
   TITI2 = "titi2",
   TaTa2 = "tATa2")
print obj 

---Code End


Here is the dump of my python environment 

-Dump Start
[EMAIL PROTECTED] ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/tool

[ python-Bugs-1583060 ] class member inconsistancies

2006-10-23 Thread SourceForge.net
Bugs item #1583060, was opened at 2006-10-23 14:13
Message generated for change (Comment added) made by santaroga
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

Please note that this 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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

CodeStart
 

class A(object):
def __init__(self):


self.argsList = []
self.dictArgs = {}
self.ARG1 = ""
self.ARG2 = ""

def multUnnammedArgs(self,
 *argsList):
if not argsList is None:
self.argsList += argsList


def multNAmmedArgument(self,
   **argDict):
if not argDict is None:
for i in argDict.iteritems():
self.dictArgs[i[0]] = i[1]

def mixedArguments(self, 
   ARG1,
   ARG2,
   *argList,
   **argDict):
self.ARG1 = ARG1
self.ARG2 = ARG2

self.multUnnammedArgs(*argList)

self.multNAmmedArgument(**argDict)

def __str__(self):
string = "Object A :"
string += "\n\t\tARG1=" + self.ARG1 
string += "\n\t\tARG2=" + self.ARG2 
string += "\n\tUnnammed Arguments"
for a in self.argsList:
string += "\n\t\t" + a

string += "\n\tNamed Arguments"
for a in self.dictArgs.iteritems():
string += "\n\t\t" + a[0] + "=" + a[1]

return string


if __name__ == '__main__':
obj = A()

obj.multUnnammedArgs("arg1", "arg2", "arg3")
print obj

obj.multNAmmedArgument(TOTO = "toto",
   TITI = "titi",
   TaTa = "tATa")

print obj   
obj.mixedArguments(ARG1="ZeArg1",
   ARG2="ZeArg2",
   TOTO2 = "toto2",
   TITI2 = "titi2",
   TaTa2 = "tATa2")
print obj 

---Code End


Here is the dump of my python environment 

-Dump Start
[EMAIL PROTECTED] ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/toolbox/python/lib

[ python-Bugs-1583060 ] class member inconsistancies

2006-10-23 Thread SourceForge.net
Bugs item #1583060, was opened at 2006-10-23 18:13
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583060&group_id=5470

Please note that this 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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: EricDaigno (santaroga)
Assigned to: Nobody/Anonymous (nobody)
Summary: class member inconsistancies

Initial Comment:
Hi...  When coding rapid classes I stumbled upon a
strange behaviour in the way python deals with data
membership of it's instances (new style) when using C
struct like container classes


behaviour changes when data members are declared in the
class itself as opposed to be declared in the __init__
method...

I understand that python does not perform any sort of
initialization outside of __init__ but this really
create confusion as to what is allowed and what is not
and is clear inconstancy that is either a language
usability bug of a plain buf in class
creation-initialization.

The problem happens when declaring a class that does
not contain __init__ method override but contains a
bunch of data elements that are initialized in the
declaration.

Expected behaviour would be that when a new instance is
created the python interpreter would create a new
instance and initialize the members as stated in the
class declaration and then call the __init__ method
(from object or the overriden __init__ from the class)

The reality is quite different.

Immutables (string) are dealt with correctly but
mutables (list, dict) are initialized only once.  Every
subsequent instantiation of the class will therefore
see new instances of member immutables objects but will
SHARE instances of the member mutables.

I have created a small programm that illustrate the
behaviour :

CodeStart
 

class A(object):
def __init__(self):


self.argsList = []
self.dictArgs = {}
self.ARG1 = ""
self.ARG2 = ""

def multUnnammedArgs(self,
 *argsList):
if not argsList is None:
self.argsList += argsList


def multNAmmedArgument(self,
   **argDict):
if not argDict is None:
for i in argDict.iteritems():
self.dictArgs[i[0]] = i[1]

def mixedArguments(self, 
   ARG1,
   ARG2,
   *argList,
   **argDict):
self.ARG1 = ARG1
self.ARG2 = ARG2

self.multUnnammedArgs(*argList)

self.multNAmmedArgument(**argDict)

def __str__(self):
string = "Object A :"
string += "\n\t\tARG1=" + self.ARG1 
string += "\n\t\tARG2=" + self.ARG2 
string += "\n\tUnnammed Arguments"
for a in self.argsList:
string += "\n\t\t" + a

string += "\n\tNamed Arguments"
for a in self.dictArgs.iteritems():
string += "\n\t\t" + a[0] + "=" + a[1]

return string


if __name__ == '__main__':
obj = A()

obj.multUnnammedArgs("arg1", "arg2", "arg3")
print obj

obj.multNAmmedArgument(TOTO = "toto",
   TITI = "titi",
   TaTa = "tATa")

print obj   
obj.mixedArguments(ARG1="ZeArg1",
   ARG2="ZeArg2",
   TOTO2 = "toto2",
   TITI2 = "titi2",
   TaTa2 = "tATa2")
print obj 

---Code End


Here is the dump of my python environment 

-Dump Start
[EMAIL PROTECTED] ~]$ python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /lesia/toolbox/python/lib/python2.4/site.pyc matches
/lesia/toolbox/python/lib/python2.4/site.py
import site # precompiled from
/lesia/toolbox/python/lib/python2.4/site.pyc
# /lesia/toolbox/python/lib/python2.4/os.pyc matches
/lesia/toolbox/python/lib/python2.4/os.py
import os # precompiled from
/lesia/toolbox/python/lib/python2.4/os.pyc
import posix # builtin
# /lesia/toolbox/python/lib/python2.4/posixpath.pyc
matches /lesia/toolbox/python/lib/python2.4/posixpath.py
import posixpath # precompiled from
/lesia/toolbox/python/lib/python2.4/posixpath.pyc
# /lesia/toolbox/python/lib/python2.4/stat.pyc matches
/lesia/toolbox/python/lib/python2.4/stat.py
import stat # precompiled from
/lesia/toolbox/python/lib/python2.4/stat.pyc
# /lesia/toolbox/python/lib/python2.4/UserDict.pyc
matches /lesia/toolbox/python/lib/python2.4/UserDict.py
import UserDict # precompiled from
/lesia/toolbox/pytho

[ python-Bugs-1582856 ] Bulding source with VC6 fails due to missing files

2006-10-23 Thread SourceForge.net
Bugs item #1582856, was opened at 2006-10-23 15:16
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582856&group_id=5470

Please note that this 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: 5
Private: No
Submitted By: Ulrich Hockenbrink (uhocke)
Assigned to: Martin v. Löwis (loewis)
Summary: Bulding source with VC6 fails due to missing files

Initial Comment:
I just downloaded the source for the 2.5 python 
library and tried to compile it under VC6.0.
The build process stops because there are three files, 
that cannot be found:

exceptions.c
md5c.c
structmodule.c




--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-10-24 00:15

Message:
Logged In: YES 
user_id=21627

It wasn't supported in Python 2.5.0. The files were still
there, but known to be non-functional.

Since that release, patches have been contributed to
reportedly make it work again. It's still not supported
anymore, i.e. it's not a release-critical bug if that build
process breaks, and reports that it broke will likely be
closed as "won't fix".

In any case, as patches have been contributed, I'm closing
this as "fixed" now - I can't actually test whether it
works, though, because I don't have VC6 anymore.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 16:45

Message:
Logged In: YES 
user_id=1627884

Yes it is. 
Under \Python-2.5\PC\VC6 you can find a Visual Studio 6.0
workspace file.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-10-23 16:37

Message:
Logged In: YES 
user_id=849994

Is building 2.5 with VC 6 still supported at all?

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:27

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:22

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

Comment By: Ulrich Hockenbrink (uhocke)
Date: 2006-10-23 15:21

Message:
Logged In: YES 
user_id=1627884

For the files exceptions.c and md5c.c it just seems to be a 
problem with the workspace file since those files exist in 
the source tree, but in different directories as expected.

For the exceptions.c, the VC workspace expects it under 
".\Python-2.5\Python" but it is in ".\Python-2.5\Modules".

For the md5c.c, there is a file called md5.c under 
".\Python-2.5\Modules", which could be the needed file.

For structmodule.c, this file cannot be found at all, 
though.

--

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



[ python-Bugs-1583276 ] Different behavior when stepping through code w/ pdb

2006-10-23 Thread SourceForge.net
Bugs item #1583276, was opened at 2006-10-24 00:54
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=1583276&group_id=5470

Please note that this 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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior when stepping through code w/ pdb

Initial Comment:
The attached test case will raise a NameError when
executed in pdb by stepping though the code.  The issue
is the EnumType name, which is both a local variable in
the Enum function which is used in the lambda and the
name of an attribute on the EnumValue class.  Since it
is a local variable used in a lambda, it's a freevar. 
What apparently happens is on line 5 the property()
result is stored in frame->f_locals['EnumType'] but it
is deleted the next time FastToLocals is invoked prior
to calling back into the debugger.  This happens when
the freevars values are merged into the locals dictionary.

The example is a stripped down version of code in
turbogears.

--

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



[ python-Bugs-1561243 ] mac installer profile patch vs. .bash_login

2006-10-23 Thread SourceForge.net
Bugs item #1561243, was opened at 2006-09-19 00:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: mac installer profile patch vs. .bash_login

Initial Comment:
The mac installer for 2.4.3 and 2.5 patches ~/.profile or ~/.bash_profile. 
If a .bash_login file exists and no .bash_profile exists the installer 
currently creates a .profile, which won't be used by bash.

--

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

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

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 11:21

Message:
Logged In: YES 
user_id=580910

This is probably fixed in 52238, 52239 and 52240 (trunk, 2.5, 2.4), but needs 
more testing to make sure that we now test for all edge condiditions.

--

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



[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9

2006-10-23 Thread SourceForge.net
Bugs item #1542949, was opened at 2006-08-18 18:51
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 6
Private: No
Submitted By: David Strozzi (dstrozzi)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: idle in python 2.5c1 freezes on macos 10.3.9

Initial Comment:
Hi,

I installed python 2.5b3 on a powerbook ppc laptop
running macos 10.3.9 a few days ago.  python and idle
worked.  Now I installed 2.5c1.  python works fine from
a terminal.  When I start idle, it loads, puts up its
menu bar, opens a shell window, displays usual startup
info, and gives me a prompt.  But, I can't type or get
a cursor. Whenever I move the mouse over the idle
window or menu bar, I get a spinning color wheel and
can't do anything.

I deleted the whole /library/python tree, reinstalled
2.5c1, and exactly the same thing happened.

Oh, and I rebooted :)

Not sure what is happening, or how to diagnose.

--

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

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

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 11:34

Message:
Logged In: YES 
user_id=580910

I've just checked in a fix for this on all 3 active branches (trunk, 2.5 and 
2.4).

BTW. The installer is supposed to install the files in Python.framework as 
owned by group admin, with mode 0664, admin users are supposed to be 
able to edit files and add new software without using sudo. That obviously 
didn't work as designed, the tree is owned by root:wheel on my 10.3.9 
testbox (the only one without a build-from-source install at the moment).

To fix this: open a terminal window and give the following command:
 
   sudo chgrp -R admin /Library/Framework/Python.framework

This will ask for a password, use your own password there. You have to be 
logged in with an admin account to do this.

--

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-26 10:01

Message:
Logged In: YES 
user_id=1056922

Great, thanks for sorting this out!

I tried the edit you suggested in your first reply.  Alas,
I'm not root on my system - I am in the admin group, but I
don't have total complete powers.  The Python.Framework dir
in /Library/Frameworks has owner admin and group wheel.  I'm
not in the wheel group, so can't edit files.

I can wait for the patch, or maybe in the future the
installer could make the group admin instead of wheel?  This
may be too esoteric to my system's setup...

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 11:46

Message:
Logged In: YES 
user_id=580910

It turns out to be a buglet in python2.5 after all. There is some code in 
distutils.sysconfig to strip out the -arch and -isysroot flags from the build 
flags 
when you ask for them through that way, but that doesn't fix all variables that 
need to be fixed.

I'll apply a patch in the morning.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-24 09:15

Message:
Logged In: YES 
user_id=580910

I'm seriously temped to call the problem you're having with numpy a bug in 
their system.

What happens is that the binary distribution for Python 2.5 (and 2.4.3 as well) 
is build as a universal binary on OSX 10.4. This is why you see '-arch ppc -
arch x86' in the compiler invocation. This works correctly on 10.4 but not on 
10.3.9, which is why distutils strips those arguments from the command-line 
on 10.3 systems.  That's all fine when you use the stock distutils, but numpy 
uses custom build commands and those don't work correctly with a universal 
build of python on 10.3.

The easiest way for you to get going again is open /Library/Frameworks/
Python.framework/Versions/2.5/lib/python2.5/config/Makefile in a text 
editor. Remove '-arch ppc -arch i386 -isysroot /Developer/SDKs/
MacOSX10.4u.sdk' from the definition of BASECFLAGS and LDFLAGS and then 
try to build numpy again


--

Comment By: David Strozzi (dstrozzi)
Date: 2006-09-22 15:35

Message:
Logged In: YES 
user_id=1056922

Hi,

Python 2.5 installs, and idle runs, perfectly on my 10.

[ python-Bugs-1570284 ] Launcher reset to factory button provides bad command-line

2006-10-23 Thread SourceForge.net
Bugs item #1570284, was opened at 2006-10-03 14:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570284&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: jjackson (jejackson)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: Launcher reset to factory button provides bad command-line

Initial Comment:
If I push the "Reset to factory settings" in Python Launcher's Preferences 
window, the command line gets a bogues "(null)" inserted, which makes a 
mess of things. I don't think that was what was intended.

In trying to debug this, I notice in the source for FileSettings.m, at line 
209
there are two duplicated lines:

[NSNumber numberWithBool: nosite], @"nosite",
[NSNumber numberWithBool: nosite], @"nosite",

Also, I notice at FileSettings.m:236

value = [dict objectForKey: @"nosite"];
if (value) nosite = [value boolValue];
value = [dict objectForKey: @"nosite"];
if (value) tabs = [value boolValue];

I'm wondering if these second "nosite"s should be "tabs", and if that 
would fix the problem.

--

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-23 19:20

Message:
Logged In: YES 
user_id=1312539

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

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-08 10:44

Message:
Logged In: YES 
user_id=580910

Fixed in revision 52229 (trunk), 52230 (2.5 branch) and 52231/52232 (2.4 
branch).

The latter checkin is a lot larger than just this fix, it is a backport of the 
entire 
universal binary support code from 2.5 to the official 2.4 tree (the 2.4.3. 
installer was build from an out-of-tree "branch").

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-10-06 03:26

Message:
Logged In: YES 
user_id=580910

I'll have a look at this this weekend. On first glance the analysis for the 
source 
code looks correct and both lines should be changed, but I don't have time just 
ow to do this and test the results just now (and then backport to the 2.5 and 
2.4 
trees)

P.S. I'll be doing a huge checking on the 2.4 branch this weekend, backporting 
the universal python stuff to the official tree. Last week was busier than 
expected, hence the late checkin.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-03 22:48

Message:
Logged In: YES 
user_id=33168

Ronald, I'm guessing that Jack still doesn't have time.  Do
you know anything about this?

--

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