[ python-Bugs-1694155 ] Python 2.5 installer ended prematurely
Bugs item #1694155, was opened at 2007-04-04 10:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Miclav (miclav)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 installer ended prematurely
Initial Comment:
Hello,
I could not install Python 2.5 on 2 machines running Windows XP. I wanted to
install it into P:\Programs\languages\python
When I run it from P:\Proginst\languages\python, the installation fails very
early : just after the "Customize Python 2.5" panel, when I click on "Next", I
get almost instantly a panel "Python 2.5 installer ended prematurely" with a
Finish button to exit installer.
When I run the msi file from C:\ as indicated in other bug report on the same
subject, I can go further but it fails also : I get first a panel "Install
Python 2.5", and some files are copied (as implied by the green status bar) but
after a while it stops with a panel saying "The specified path is too long :
P:\Programs" and 2 buttons to retry or cancel installation. Retry brings again
to this panel so I must cancel.
I was unable to find a solution, and I generated a python.log file (for the
installation from C:\) that I join as attached file.
On a third machine with Windows 2000 I succeeded in installing Python 2.5 in
P:\Programs\languages\python from P:\Proginst\languages\python, so maybe the
problem comes from WinXP? In both cases (XP and 2000) I use Zone Alarm as
firewall (for XP, with XP firewall desactivated).
The only solution I found up to now is to install Python 2.2 (which uses
another installer). I would be very happy if you could switch to an Open Source
installation program (not commercial) so that everything in the behaviour of
installation program can be known and under control. From the python.log file,
I suspect that msi installer in WinXP might use some spy program, or it may in
future versions of Windows. The installation with msi installer is much too
fragile, and it might make fragile all Open Source programs based on Python :
before trying to install Python, I had tried to install the programm Leo,
which is an editor written in Python that installs Python as a first step if it
is not already installed. And I failed also to install Leo, with the same error
(path P:\programs too long").
I would suggest to switch to NSIS ("Nullsoft Installer"), which is Open Source.
I use it to distribute my own programs, and I found it excellent. I found
further that many other Open Source programs are using this installer, and it
always worked like a charm on all my machines. It seems much more robust that
msi installer.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1690840 ] xmlrpclib methods submit call on __str__, __repr__
Bugs item #1690840, was opened at 2007-03-29 15:14
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Greg Hazel (ghazel)
>Assigned to: Fredrik Lundh (effbot)
Summary: xmlrpclib methods submit call on __str__, __repr__
Initial Comment:
Notice how trying to print a method causes it to submit the call:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError: >> f = s.somecall
>>> locals()
{'f': Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "c:\python25\lib\xmlrpclib.py", line 1437, in __request
verbose=self.__verbose
File "c:\python25\lib\xmlrpclib.py", line 1191, in request
headers
xmlrpclib.ProtocolError:
--
>Comment By: Collin Winter (collinwinter)
Date: 2007-04-04 11:10
Message:
Logged In: YES
user_id=1344176
Originator: NO
Fredrik, you originally wrote xmlrpclib: any objections to stringifying
_Method objects to something like ""?
--
Comment By: Greg Hazel (ghazel)
Date: 2007-04-04 02:45
Message:
Logged In: YES
user_id=731668
Originator: YES
This would be reasonable:
>>> from xmlrpclib import ServerProxy
>>> s = ServerProxy("http://google.com";)
>>> print s.somecall
Similarly:
>>> f = s.somecall
>>> locals()
{'f': , '__builtins__': , 's': , '__name__':
'__main__
', 'ServerProxy': , '__doc__':
None}
Bonus points for:
>
--
Comment By: Collin Winter (collinwinter)
Date: 2007-03-29 22:59
Message:
Logged In: YES
user_id=1344176
Originator: NO
What would you rather seem them print?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1690840&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693753 ] Portability issue: os.rename behaves differently on win32
Bugs item #1693753, was opened at 2007-04-03 12:17 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: cs_ (cs_) Assigned to: Nobody/Anonymous (nobody) >Summary: Portability issue: os.rename behaves differently on win32 Initial Comment: os.rename(src, dst) fails on Windows if dst already exist and regular file. On Unixes, it does not fail, and silently overwrites dst. It's better to use MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under Win32 to make it behave consistent way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694155 ] Python 2.5 installer ended prematurely
Bugs item #1694155, was opened at 2007-04-04 05:03
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Miclav (miclav)
>Assigned to: Martin v. Löwis (loewis)
Summary: Python 2.5 installer ended prematurely
Initial Comment:
Hello,
I could not install Python 2.5 on 2 machines running Windows XP. I wanted to
install it into P:\Programs\languages\python
When I run it from P:\Proginst\languages\python, the installation fails very
early : just after the "Customize Python 2.5" panel, when I click on "Next", I
get almost instantly a panel "Python 2.5 installer ended prematurely" with a
Finish button to exit installer.
When I run the msi file from C:\ as indicated in other bug report on the same
subject, I can go further but it fails also : I get first a panel "Install
Python 2.5", and some files are copied (as implied by the green status bar) but
after a while it stops with a panel saying "The specified path is too long :
P:\Programs" and 2 buttons to retry or cancel installation. Retry brings again
to this panel so I must cancel.
I was unable to find a solution, and I generated a python.log file (for the
installation from C:\) that I join as attached file.
On a third machine with Windows 2000 I succeeded in installing Python 2.5 in
P:\Programs\languages\python from P:\Proginst\languages\python, so maybe the
problem comes from WinXP? In both cases (XP and 2000) I use Zone Alarm as
firewall (for XP, with XP firewall desactivated).
The only solution I found up to now is to install Python 2.2 (which uses
another installer). I would be very happy if you could switch to an Open Source
installation program (not commercial) so that everything in the behaviour of
installation program can be known and under control. From the python.log file,
I suspect that msi installer in WinXP might use some spy program, or it may in
future versions of Windows. The installation with msi installer is much too
fragile, and it might make fragile all Open Source programs based on Python :
before trying to install Python, I had tried to install the programm Leo,
which is an editor written in Python that installs Python as a first step if it
is not already installed. And I failed also to install Leo, with the same error
(path P:\programs too long").
I would suggest to switch to NSIS ("Nullsoft Installer"), which is Open Source.
I use it to distribute my own programs, and I found it excellent. I found
further that many other Open Source programs are using this installer, and it
always worked like a charm on all my machines. It seems much more robust that
msi installer.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368768 ] clearing up dictionary keys/set member docs
Bugs item #1368768, was opened at 2005-11-29 02:40 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: clearing up dictionary keys/set member docs Initial Comment: The documentation for dictionaries says "A dictionary's keys are almost arbitrary values. Only values containing lists, dictionaries or other mutable types (that are compared by value rather than by object identity) may not be used as keys." This is wrong. tuples are an immutable type, but not all tuples can be used as keys. The set documentation says "A set object is an unordered collection of immutable values.". This is also wrong - at least for common definitions of immutable. Immutability is a convenient way of dealing with builtin types, but is a red herring. It's whether or not the object has a hash value that matters, and it's the behavior of that hash value (coupled with comparison) that determine whether or not things behave as expected. The __hash__ documentation deals with these issues. I suggest replacing the current descriptions with one that references hashing, and a footnote pointing to the __hash__ docs for details: Any hashable object(1) can be used as a dictionary key/set element. Lists, sets and dicts are not hashable, and can not be used. Tuples can be used if all the things they contain are hashable. Instances of all other built-in types and most user-defined classes are hashable. (1) Objects for which the hash() function returns an appropriate value. See the __hash__ documentation for details. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-04-04 19:11 Message: Logged In: YES user_id=51702 Originator: NO That patch have been committed, this bug should be closed. -- Comment By: Collin Winter (collinwinter) Date: 2006-01-05 13:28 Message: Logged In: YES user_id=1344176 I have submitted patch #1397711 which resolves this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694442 ] Failure to build on AIX 5.3
Bugs item #1694442, was opened at 2007-04-04 10:34 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=1694442&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jaman Swearingen (tiriss) Assigned to: Nobody/Anonymous (nobody) Summary: Failure to build on AIX 5.3 Initial Comment: AIX 5.3.0.0 gcc 4.0.0 tk8.4 tcl8.4 xlc_r 6.0.0 cc_r 6.0.0 Regardless of which of the compilers I use gcc, xlc_r, or cc_r, I get the following error after I hit make: creating build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/opt/freeware/src/packages/Python-2.5/./Include -I./Include -I. -I/usr/local/include -I/opt/freeware/src/packages/Python-2.5/Include -I/opt/freeware/src/packages/Python-2.5 -c /opt/freeware/src/packages/Python-2.5/Modules/_struct.c -o build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules/_struct.o creating build/lib.aix-5.3-2.5 ./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-5.3-2.5/opt/freeware/src/packages/Python-2.5/Modules/_struct.o -L/usr/local/lib -lpython2.5 -o build/lib.aix-5.3-2.5/_struct.so collect2: library libpython2.5 not found *** WARNING: renaming "_struct" since importing it failed: 0509-022 Cannot load module build/lib.aix-5.3-2.5. 0509-026 System error: A file or directory in the path name does not exist. error: No such file or directory For some reason when I use xlc_r or gcc, it fails to find the local libpython2.5.a library that is residing in the current directory. When I use cc_r, it fails to find libtcl8.4.so and libtk8.4.so even though there are copies of those in the local . directory. Any help would be appreciated. Here are the configures I used: ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" \ --disable-ipv6 AR="ar -X64" --enable-shared or ./configure --with-gcc --with-cxx=g++ \ --disable-ipv6 --enable-shared or configure --disable-ipv6 Let me know if there is other information you need. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694442&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1368768 ] clearing up dictionary keys/set member docs
Bugs item #1368768, was opened at 2005-11-28 20:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: clearing up dictionary keys/set member docs Initial Comment: The documentation for dictionaries says "A dictionary's keys are almost arbitrary values. Only values containing lists, dictionaries or other mutable types (that are compared by value rather than by object identity) may not be used as keys." This is wrong. tuples are an immutable type, but not all tuples can be used as keys. The set documentation says "A set object is an unordered collection of immutable values.". This is also wrong - at least for common definitions of immutable. Immutability is a convenient way of dealing with builtin types, but is a red herring. It's whether or not the object has a hash value that matters, and it's the behavior of that hash value (coupled with comparison) that determine whether or not things behave as expected. The __hash__ documentation deals with these issues. I suggest replacing the current descriptions with one that references hashing, and a footnote pointing to the __hash__ docs for details: Any hashable object(1) can be used as a dictionary key/set element. Lists, sets and dicts are not hashable, and can not be used. Tuples can be used if all the things they contain are hashable. Instances of all other built-in types and most user-defined classes are hashable. (1) Objects for which the hash() function returns an appropriate value. See the __hash__ documentation for details. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-04-04 12:11 Message: Logged In: YES user_id=51702 Originator: NO That patch have been committed, this bug should be closed. -- Comment By: Collin Winter (collinwinter) Date: 2006-01-05 07:28 Message: Logged In: YES user_id=1344176 I have submitted patch #1397711 which resolves this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694155 ] Python 2.5 installer ended prematurely
Bugs item #1694155, was opened at 2007-04-04 12:03
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Miclav (miclav)
Assigned to: Martin v. Löwis (loewis)
Summary: Python 2.5 installer ended prematurely
Initial Comment:
Hello,
I could not install Python 2.5 on 2 machines running Windows XP. I wanted to
install it into P:\Programs\languages\python
When I run it from P:\Proginst\languages\python, the installation fails very
early : just after the "Customize Python 2.5" panel, when I click on "Next", I
get almost instantly a panel "Python 2.5 installer ended prematurely" with a
Finish button to exit installer.
When I run the msi file from C:\ as indicated in other bug report on the same
subject, I can go further but it fails also : I get first a panel "Install
Python 2.5", and some files are copied (as implied by the green status bar) but
after a while it stops with a panel saying "The specified path is too long :
P:\Programs" and 2 buttons to retry or cancel installation. Retry brings again
to this panel so I must cancel.
I was unable to find a solution, and I generated a python.log file (for the
installation from C:\) that I join as attached file.
On a third machine with Windows 2000 I succeeded in installing Python 2.5 in
P:\Programs\languages\python from P:\Proginst\languages\python, so maybe the
problem comes from WinXP? In both cases (XP and 2000) I use Zone Alarm as
firewall (for XP, with XP firewall desactivated).
The only solution I found up to now is to install Python 2.2 (which uses
another installer). I would be very happy if you could switch to an Open Source
installation program (not commercial) so that everything in the behaviour of
installation program can be known and under control. From the python.log file,
I suspect that msi installer in WinXP might use some spy program, or it may in
future versions of Windows. The installation with msi installer is much too
fragile, and it might make fragile all Open Source programs based on Python :
before trying to install Python, I had tried to install the programm Leo,
which is an editor written in Python that installs Python as a first step if it
is not already installed. And I failed also to install Leo, with the same error
(path P:\programs too long").
I would suggest to switch to NSIS ("Nullsoft Installer"), which is Open Source.
I use it to distribute my own programs, and I found it excellent. I found
further that many other Open Source programs are using this installer, and it
always worked like a charm on all my machines. It seems much more robust that
msi installer.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-04-04 20:11
Message:
Logged In: YES
user_id=21627
Originator: NO
Is P a subst'ed drive, by any chance?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694155&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686475 ] os.stat() WindowsError 13 when file in use
Bugs item #1686475, was opened at 2007-03-23 03:31
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: d roberts (dcroberts)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat() WindowsError 13 when file in use
Initial Comment:
Using 2.5 Sept 19, 2006 on Windows XP, 32-bit.
os.stat() on an "in use" file (i.e., open by another process) erroneously
returns WindowsError [Error 13]. The file stats should be available on an open
file, even if you cannot read/write the file itself.
Python 2.4 correctly returns the stats on the file.
CORRECT in 2.4:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
>>> import os
>>> os.stat('c:\\hiberfil.sys')
(33206, 0L, 2, 1, 0, 0, 804311040L, 1173962381, 1173962381, 1069302780)
-
ERROR in 2.5:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> os.stat("c:\\hiberfil.sys")
Traceback (most recent call last):
File "", line 1, in
WindowsError: [Error 13] The process cannot access the file because it is being
used by another process: 'c:\\hiberfil.sys'
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-04-04 20:31
Message:
Logged In: YES
user_id=21627
Originator: NO
I have now committed this patch as r54685 and r54686.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-30 08:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Attached is a patch that makes it fall back to FindFirstFile if
GetFileAttributesEx fail with ERROR_SHARING_VIOLATION.
File Added: stat.diff
--
Comment By: d roberts (dcroberts)
Date: 2007-03-23 18:49
Message:
Logged In: YES
user_id=1750755
Originator: YES
Taking your hint, I just looked at the code in 42230 which uses the Win32
GetFileAttributesEx() function. This function does indeed return an error
for an in-use file. Not sure if this is a "feature" or "bug" in the
underlying Windows function. I did try FindFirstFile(), which is able to
return info on an in-use file. Not sure if this is a reasonable alternative
to GFAE(), but wanted to make folks aware of the possibility. It's probably
slower, since it can handle wild-cards, and returns a handle for subsequent
calls to FindNextFile(). The handle must be closed with FindClose(). I'm
not sure what underlying mechanism FindFirstFile() uses, but I'm assuming
it accesses the "directory" to get its information, rather than trying to
access the file itself. FWIW.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-23 11:24
Message:
Logged In: YES
user_id=21627
Originator: NO
It certainly is; Python is likely opening the file in the wrong mode now.
I'll investigate, although contributions would be welcome.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-23 11:15
Message:
Logged In: YES
user_id=849994
Originator: NO
May this be related to rev. 42230 - "Drop C library for stat/fstat on
Windows." ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686475&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563759 ] struct.unpack doens't support buffer protocol objects
Bugs item #1563759, was opened at 2006-09-22 17:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: struct.unpack doens't support buffer protocol objects Initial Comment: If you pass an object which supports the buffer protocol to struct.unpack it will fail because it specifically checks for a string. You should use PyObject_AsReadBuffer instead. If this code is performance critical, you could add an unpack_buffer method or something like that. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-04 15:32 Message: Logged In: YES user_id=80475 Originator: NO Fixed. See revision 54690. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-03 19:45 Message: Logged In: YES user_id=80475 Originator: NO This was due to Bob Ippolito's commit in revision 46184. -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 07:57 Message: Logged In: YES user_id=1067739 test_struct_run.py works in 2.4, throws exception in 2.5 -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 07:56 Message: Logged In: YES user_id=1067739 The actual code which broke used a Pointer extension class implemented in C++. I reproduced the problem using array.array. Using array in this way (without calling tostring) looks a bit weird. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 07:12 Message: Logged In: YES user_id=21627 Ah, so you say that was working previously? It's a bug, then. Can you provide a test case? -- Comment By: Adal Chiriliuc (adalx) Date: 2006-09-23 06:37 Message: Logged In: YES user_id=1067739 Well, because it broke previously working code and there is no warning in the documentation about that. In the mean-time, I've found out about pack_into and unpack_from which accept buffer like objects. Note that they are not documented in the struct module section, only mentioned in the "What's new" chapter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-23 06:19 Message: Logged In: YES user_id=21627 Why is this a bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563759&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678102 ] zlib.crc32() not cross-platform
Bugs item #1678102, was opened at 2007-03-10 18:07
Message generated for change (Settings changed) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Ben Collver (bencollver)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib.crc32() not cross-platform
Initial Comment:
The zlib.crc32() function sometimes produces different results for the same
input on big and little-endian processors. Same for zlib.adler32().
sparc64:
>>> import zlib
>>> print zlib.adler32("--", 1)
> 3763407051
>>> print zlib.crc32("--", 1)
3044228349
i386:
>>> import zlib
>>> print zlib.adler32("--", 1)
> -531560245
>>> print zlib.crc32("--", 1)
-1250738947
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-03-13 18:52
Message:
Logged In: YES
user_id=479790
Originator: NO
py> -531560245 & 0x
3763407051L
It's the same number (actually, the same bit pattern). The i386 version is
signed, the other unsigned. The i386 platform uses a 32 bit "int"; the
sparc64 uses 64 bits (I presume). 3763407051 doesnt fit in 31bits, so it's
seen as a negative number.
--
Comment By: Ben Collver (bencollver)
Date: 2007-03-10 18:13
Message:
Logged In: YES
user_id=778667
Originator: YES
The extra > characters before the first results come from me pasting the
results to my irc client, then copying from there and pasting here. Sorry
for any confusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1662581 ] the re module can perform poorly: O(2**n) versus O(n**2)
Feature Requests item #1662581, was opened at 2007-02-17 18:39 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1662581&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: Performance >Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: the re module can perform poorly: O(2**n) versus O(n**2) Initial Comment: in short, the re module can degenerate to really really horrid performance. See this for how and why: http://swtch.com/~rsc/regexp/regexp1.html exponential decline instead of squared. I don't have a patch so i'm filing this bug as a starting point for future work. The Modules/_sre.c files implementation could be updated to use the parallel stepping Thompson approach instead of recursive backtracking. filing this as a bug until me or someone else comes up with a patch. -- Comment By: Gregory P. Smith (greg) Date: 2007-02-22 17:30 Message: Logged In: YES user_id=413 Originator: YES yeah this is better as a feature request. certianly low priority either way. -nothing- I propose doing would change the syntax or behaviour of existing regular expressions at all. Doing so would be a disaster. thompson nfa does not imply changing the behaviour. anyways its a lot more than a simple "patch" to change the re module to not use backtracking so i expect this to languish unless someone has a of free time and motivation all at once. :) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-02-22 03:51 Message: Logged In: YES user_id=341410 Originator: NO I would file this under "feature request"; the current situation isn't so much buggy, as slow. While you can produce a segfault with the current regular expression engine (due to stack overflow), you can do the same thing with regular Python on Linux (with sys.setrecursionlimit), ctypes, etc., and none of those are considered as buggy. My only concern with such a change is that it may or may not change the semantics of the repeat operators '*' and '+', which are currently defined as "greedy". If I skimmed the article correctly late at night, switching to a Thompson family regular expression engine may result in those operators no longer being greedy. Please correct me if I am wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1662581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694663 ] Overloading int.__pow__ does not work
Bugs item #1694663, was opened at 2007-04-04 19:44 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=1694663&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Overloading int.__pow__ does not work Initial Comment: >From c.l.p: in response to glitch report, 2nd person showed that it is >specific to __pow__ >>> class MyInt(int): ... __sub__ = int.__add__ # similar lines for 9 other methods omitted ... __or__ = int.__add__ ... __pow__ = int.__add__ ... >>> i = MyInt(42) >>> i + 3 45 >>> i - 3 45 # similar outputs omitted >>> i | 3 45 >>> i ** 3 74088 Another person (3rd) confirmed presence in 2.5 Python 2.5 (r25:51908, Jan 21 2007, 03:10:25) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694663 ] Overloading int.__pow__ does not work
Bugs item #1694663, was opened at 2007-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Overloading int.__pow__ does not work Initial Comment: >From c.l.p: in response to glitch report, 2nd person showed that it is >specific to __pow__ >>> class MyInt(int): ... __sub__ = int.__add__ # similar lines for 9 other methods omitted ... __or__ = int.__add__ ... __pow__ = int.__add__ ... >>> i = MyInt(42) >>> i + 3 45 >>> i - 3 45 # similar outputs omitted >>> i | 3 45 >>> i ** 3 74088 Another person (3rd) confirmed presence in 2.5 Python 2.5 (r25:51908, Jan 21 2007, 03:10:25) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] -- >Comment By: Ziga Seilnacht (zseil) Date: 2007-04-05 03:47 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch (with tests) that should fix this. There was another problem when the slot wrapper came from a different type: >>> class MyInt(int): ... __mul__ = float.__add__ ... >>> MyInt(3) * 3 9 This now raises a TypeError. File Added: mixing_slots.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1694663 ] Overloading int.__pow__ does not work
Bugs item #1694663, was opened at 2007-04-04 18:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.5 Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Terry J. Reedy (tjreedy) >Assigned to: Raymond Hettinger (rhettinger) Summary: Overloading int.__pow__ does not work Initial Comment: >From c.l.p: in response to glitch report, 2nd person showed that it is >specific to __pow__ >>> class MyInt(int): ... __sub__ = int.__add__ # similar lines for 9 other methods omitted ... __or__ = int.__add__ ... __pow__ = int.__add__ ... >>> i = MyInt(42) >>> i + 3 45 >>> i - 3 45 # similar outputs omitted >>> i | 3 45 >>> i ** 3 74088 Another person (3rd) confirmed presence in 2.5 Python 2.5 (r25:51908, Jan 21 2007, 03:10:25) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-04 23:54 Message: Logged In: YES user_id=80475 Originator: NO I'll take a look at your patch. The root problem is that the wrapper functions will return NULL if they are fed the wrong number of arguments (i.e. the int.__add__ wrapper expects exactly two arguments but the ** call provides three) -- you will see a similar result if int.__neg__ or int.__invert__ are assigned to __add__. It looks like an upstream step is seeing the NULL and deciding that it needs to look to skip the given method call and instead try the base the class. Am lowering the priority because there is no good use case for deliberate argument mismatches in the override. Am leaving the bug open because we want the appropriate error message to surface. -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-04 20:47 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch (with tests) that should fix this. There was another problem when the slot wrapper came from a different type: >>> class MyInt(int): ... __mul__ = float.__add__ ... >>> MyInt(3) * 3 9 This now raises a TypeError. File Added: mixing_slots.diff -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1694663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686597 ] descrintro: error describing __new__ behavior
Bugs item #1686597, was opened at 2007-03-23 06:47 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: descrintro: error describing __new__ behavior Initial Comment: descrintro (http://www.python.org/download/releases/2.2.3/descrintro/#__new__) linked from http://www.python.org/doc/newstyle/ still says: "__new__ must return an object. [...] If you return an object of a different class, its __init__ method will be called." But since Revision 26220 - Modified Sat Apr 6 01:05:01 2002 UTC (4 years, 11 months ago) by gvanrossum: "Changed new-style class instantiation so that when C's __new__ method returns something that's not a C instance, its __init__ is not called. [SF bug #537450]" That is, exactly the opposite as said on descrintro. The documentation for __new__ in the Reference manual, section 3.4.1, is correct and says: "If __new__() does not return an instance of cls, then the new instance's __init__() method will not be invoked." Note that the modified behavior was already present on version 2.2.3 (and later) so updating the document currently at /download/releases/2.2.3/ would be fine. -- >Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-05 02:00 Message: Logged In: YES user_id=479790 Originator: YES Yes, but descrintro is the very first reference under http://www.python.org/doc/newstyle/ "and should be your starting point." (citing that page) Surely there are other documents a bit outdated, but being descrintro in such a prominent place, should have a correct content. -- Comment By: Steven Bethard (bediviere) Date: 2007-04-03 18:47 Message: Logged In: YES user_id=945502 Originator: NO Note that this is correct in the documentation: http://docs.python.org/ref/customization.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686597&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
