[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
