[ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with exceptions
Bugs item #1117670, was opened at 2005-02-07 15:50
Message generated for change (Comment added) made by spiv
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiler: Bad return and Bad call errors with exceptions
Initial Comment:
I ran into a weird error when trying to profile a test
script of mine:
AssertionError: ('Bad call', ('', 0, 'encode'))
I managed to whittle it down to some minimal test
cases, which are attached (although the errors they
generate are slightly different.)
$ python-cvs -m profile profile_badcall.py
Traceback (most recent call last):
[snipped ...]
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
File "", line 1, in ?
File "profile_badcall.py", line 10, in ?
os.path.join("C",'b')
File
"/home/donut/usr64/python/lib/python2.5/posixpath.py",
line 56, in join
def join(a, *p):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 285, in trace_dispatch_call
assert (self.cur is None or AssertionError: ('Bad call',
('profile_badcall.py', 2,
'trier'))
$ python-cvs -m profile profile_badreturn.py
Traceback (most recent call last):
[snipped...]
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
File "", line 1, in ?
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 312, in trace_dispatch_return
assert frame is self.cur[-2].f_back, ("Bad return",
self.cur[-3])
AssertionError: ('Bad return', ('profile_badreturn.py',
1, 'trier'))
The errors occur in python CVS as of 20050206 and
python 2.4, but not in python 2.3.4.
OS: debian sid (3.1)
Arch: amd64
--
Comment By: Andrew Bennetts (spiv)
Date: 2005-10-08 17:05
Message:
Logged In: YES
user_id=50945
I still see this in current python 2.4, but not in current
python CVS.
Also, hotshot seems to work ok in 2.4 and CVS.
OS: ubuntu breezy (5.10)
Arch: i386
--
Comment By: Gary Oberbrunner (garyoberbrunner)
Date: 2005-03-09 14:35
Message:
Logged In: YES
user_id=417980
Is there any news on this bug? It is possibly preventing
scons (http://scons.org) from being profiled on python 2.4
-- we get the same errors as above. Test case is too large
to include here, but please email me with any news if
possible! Would be glad to test a fix.
-- Gary
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1316162 ] Segmentation fault with invalid "coding"
Bugs item #1316162, was opened at 2005-10-07 13:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
>Resolution: Works For Me
Priority: 7
Submitted By: Humberto Diógenes (virtualspirit)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: Segmentation fault with invalid "coding"
Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-
2. Run it:
python wrong_coding.py
3. Enjoy your segfault... :P
Versions tested:
- Python 2.4.2 (Ubuntu Breezy)
- Python 2.3.5 (Debian Sarge)
Running it directly with "python -c" gives MemoryError. Strace output:
# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(2, "MemoryError", 11MemoryError) = 11
write(2, "\n", 1
) = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER,
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1) = ?
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-08 00:21
Message:
Logged In: YES
user_id=33168
Are you sure you can reproduce with 2.4 CVS branch. I just
fixed this recently (Fix segfault with invalid coding. in
Misc/NEWS). I can't reproduce on 2.4 CVS. I expect this
probem exists in 2.4.2 and earlier. Checked in around
2005/10/02 at 01:48:49, bug #772896.
The memory error was fixed in CVS, but not backported.
That's up to Anthony (release manager).
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-07 23:24
Message:
Logged In: YES
user_id=1188172
Reproducable here with 2.4.2 and the 2.4 CVS branch. It
seems fixed in HEAD.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 02:27 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=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 17:27 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:09 Message: Logged In: YES user_id=1038590 This problem doesn't exist in Python 2.4: Py> class Queue(list): ... def __setitem__(self, a, v): ... print "old setitem" ... def mysetitem(self, i, v): ... print "new setitem" ... def use_mysetitem(self): ... self.__setitem__ = self.mysetitem ... Py> x = Queue() Py> Py> x[1] = 2 old setitem Py> Py> x.__setitem__(2, 3) old setitem Py> Py> x.use_mysetitem() Py> x[3] = 4 old setitem Py> Py> x.__setitem__(4, 5) new setitem -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 02:27 Message generated for change (Comment added) made by capnstabn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- >Comment By: capnSTABN (capnstabn) Date: 2005-10-08 03:14 Message: Logged In: YES user_id=1126596 err, yeh it does 8) the last TWO prints should display new setitem -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 03:09 Message: Logged In: YES user_id=1038590 This problem doesn't exist in Python 2.4: Py> class Queue(list): ... def __setitem__(self, a, v): ... print "old setitem" ... def mysetitem(self, i, v): ... print "new setitem" ... def use_mysetitem(self): ... self.__setitem__ = self.mysetitem ... Py> x = Queue() Py> Py> x[1] = 2 old setitem Py> Py> x.__setitem__(2, 3) old setitem Py> Py> x.use_mysetitem() Py> x[3] = 4 old setitem Py> Py> x.__setitem__(4, 5) new setitem -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 17:27 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:22 Message: Logged In: YES user_id=1038590 Ah, sorry. I was looking at the wrong part of the printout. -- Comment By: capnSTABN (capnstabn) Date: 2005-10-08 18:14 Message: Logged In: YES user_id=1126596 err, yeh it does 8) the last TWO prints should display new setitem -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:09 Message: Logged In: YES user_id=1038590 This problem doesn't exist in Python 2.4: Py> class Queue(list): ... def __setitem__(self, a, v): ... print "old setitem" ... def mysetitem(self, i, v): ... print "new setitem" ... def use_mysetitem(self): ... self.__setitem__ = self.mysetitem ... Py> x = Queue() Py> Py> x[1] = 2 old setitem Py> Py> x.__setitem__(2, 3) old setitem Py> Py> x.use_mysetitem() Py> x[3] = 4 old setitem Py> Py> x.__setitem__(4, 5) new setitem -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 17:27 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:34 Message: Logged In: YES user_id=1038590 And now that I've read the bug report properly, I'm closing it as "Not a bug" :) To affect the operators you need to alter the slot on the *class*, not on the instance, but your "use_mysetitem" method only affects the current instance - it shadows the slot in the instance dictionary, but the interpreter is only interested in the slots in the class itself. To make the method work, it needs to be a class method: def use_mysetitem(cls): cls.__setitem__ = cls.mysetitem use_mysetitem = classmethod(use_mysetitem) Of course, it will then affect *all* instances of the class once the change is made. You can get per-instance swapping by writing the slot method in such a way that it delegates to a normal method, which you can then alter on a per-instance basis. The wisdom of actually *doing* that is debatable though ;) -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:22 Message: Logged In: YES user_id=1038590 Ah, sorry. I was looking at the wrong part of the printout. -- Comment By: capnSTABN (capnstabn) Date: 2005-10-08 18:14 Message: Logged In: YES user_id=1126596 err, yeh it does 8) the last TWO prints should display new setitem -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 18:09 Message: Logged In: YES user_id=1038590 This problem doesn't exist in Python 2.4: Py> class Queue(list): ... def __setitem__(self, a, v): ... print "old setitem" ... def mysetitem(self, i, v): ... print "new setitem" ... def use_mysetitem(self): ... self.__setitem__ = self.mysetitem ... Py> x = Queue() Py> Py> x[1] = 2 old setitem Py> Py> x.__setitem__(2, 3) old setitem Py> Py> x.use_mysetitem() Py> x[3] = 4 old setitem Py> Py> x.__setitem__(4, 5) new setitem -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1317376 ] irregular behavior within class using __setitem__
Bugs item #1317376, was opened at 2005-10-08 02:27 Message generated for change (Comment added) made by capnstabn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: irregular behavior within class using __setitem__ Initial Comment: i found two bugs vaguely similar to this posted but i think they were different bugs in theory, and both were deemed 'features' anyway so ... :p basically the class is a modified list, being used as a queue what happens is, when hotswapping the __setitem__ functionality, unless explicitly calling __setitem__, the old __setitem__ continues to be called this is very odd and as far as i can tell the behavior is undocumented class Queue(list): def __setitem__(self, a, v): print "old setitem" def mysetitem(self, i, v): print "new setitem" def use_mysetitem(self): self.__setitem__ = self.mysetitem x = Queue() x[1] = 2 x.__setitem__(2, 3) x.use_mysetitem() x[3] = 4 x.__setitem__(4, 5) -- >Comment By: capnSTABN (capnstabn) Date: 2005-10-08 04:44 Message: Logged In: YES user_id=1126596 omg! you're lucky people on freenode spared you a half hour of explaining that lol! and after almost 4 hours of completely going around the world just to take one step backwards... [05:38] what if i want to change the class within an instance method [05:38] coz the whole method isnt a class method [05:38] Then you can use self.__class__ haha thanks! -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 03:34 Message: Logged In: YES user_id=1038590 And now that I've read the bug report properly, I'm closing it as "Not a bug" :) To affect the operators you need to alter the slot on the *class*, not on the instance, but your "use_mysetitem" method only affects the current instance - it shadows the slot in the instance dictionary, but the interpreter is only interested in the slots in the class itself. To make the method work, it needs to be a class method: def use_mysetitem(cls): cls.__setitem__ = cls.mysetitem use_mysetitem = classmethod(use_mysetitem) Of course, it will then affect *all* instances of the class once the change is made. You can get per-instance swapping by writing the slot method in such a way that it delegates to a normal method, which you can then alter on a per-instance basis. The wisdom of actually *doing* that is debatable though ;) -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 03:22 Message: Logged In: YES user_id=1038590 Ah, sorry. I was looking at the wrong part of the printout. -- Comment By: capnSTABN (capnstabn) Date: 2005-10-08 03:14 Message: Logged In: YES user_id=1126596 err, yeh it does 8) the last TWO prints should display new setitem -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-10-08 03:09 Message: Logged In: YES user_id=1038590 This problem doesn't exist in Python 2.4: Py> class Queue(list): ... def __setitem__(self, a, v): ... print "old setitem" ... def mysetitem(self, i, v): ... print "new setitem" ... def use_mysetitem(self): ... self.__setitem__ = self.mysetitem ... Py> x = Queue() Py> Py> x[1] = 2 old setitem Py> Py> x.__setitem__(2, 3) old setitem Py> Py> x.use_mysetitem() Py> x[3] = 4 old setitem Py> Py> x.__setitem__(4, 5) new setitem -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1317376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 14:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 11:56 Message: Logged In: YES user_id=21627 Can somebody please study the source of the C runtime of VS2005 (probably needs to be requested specifically during installation), to find out whether more generic solutions are available. Possible solutions include: - don't call signal, but call an alternative function instead which won't cause a crash - set some magic variable, disabling the error checking - fetch the list of supported signals from somewhere (at compile time or at run time), and iterate over that list. Anyway, I don't see the official Python 2.5 release built with VS 2005, so this is a minor issue - I rather expect Python to skip VS 2005, and go right to the version that succeeds it. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 10:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 21:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 20:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. -- Comment By: Michael Hudson (mwh) Date: 2005-10-03 15:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix it for the final release. If it is released, though, I guess we need to do something like you suggest (along with some colourful comments, I guess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311579 ] 2.4.2 make problems
Bugs item #1311579, was opened at 2005-10-03 09:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Mothersdill (nlhas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.2 make problems Initial Comment: Recommended to post this as a bug in comp.lang. python: Reply from Reinhold Birkenfeld > I have a standard Debian x86 system with Python 2.4.1 (compiled from > source). Attempts to compile 2.4.2 fail with references to Unicode -- > is there a basic system library that's missing? > Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold + No: nothing unusual that I can see in configure output -- I can post config.log if necessary. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 12:03 Message: Logged In: YES user_id=21627 Do you have an Objects/unicodeobject.o in your build tree? If yes, can you please do nm Objects/unicodeobject.o > unicodesyms.txt and attach the resulting file, as well as ar tv libpython2.4.a|grep unicode and report the output of this command? TIA. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType
Bugs item #1306484, was opened at 2005-09-28 06:49 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vágvölgyi Attila (wigy) >Assigned to: Nobody/Anonymous (nobody) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-29 10:29 Message: Logged In: YES user_id=156682 loewis, I confess I could not understand a word. But as I see, it would have some advantages to have a completely unicode internal filename representation on systems having multiple filesystems mounted with different encodings, or systems having simply utf-8 filesystems (no 'ascii', 'replace' for allowing two filenames differing only in accents). I agree with Joel Spolsky (http://www.joelonsoftware.com/articles/Unicode.html), and I think that if choosing unicode could be easier in a language, than most of l10n problems would be solved. I understand, that coding unicode in C is a pain. Imagine - theoretically - if a literal like "hello" would automatically mean a unicode object in python, and you had to write s"hello" to make a literal string object encoded in a way some enviromental settings (or maybe the PEP 0263 header of the specific source file?) determine, so you have control on what happens. Imagine the case when there is a latin1 and a utf-8 partition mounted, and the console is latin2! Life would be much, much easier for a non-American programmer if she had to be aware from the first moment, that she is in an international environment. -- Comment By: Georg Brandl (gbrandl) Date: 2005-09-29 08:34 Message: Logged In: YES user_id=849994 Sounds sound. :) -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 08:20 Message: Logged In: YES user_id=21627 Why couldn't co_filename just be the Unicode string? I think one would have to change: - code_repr, to convert the filename into a byte string (preferably using 'ascii', 'replace') - tb_printinternal (not sure what to do here) - code_new, to accept either strings or unicode strings - builtin_compile, which probably indeed needs to convert the string using the file system encoding, and then patch the resulting code object to point to the unicode object originally passed (unless we can accept more pythonrun functions). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket
Bugs item #1302793, was opened at 2005-09-24 07:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: IamPaul (heartlesshind) Assigned to: Martin v. Löwis (loewis) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 12:06 Message: Logged In: YES user_id=21627 Closing because of lack of response. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 16:05 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. What specific file did you download and install? What is the contents of the DLLs directory? Do you have, by any chance, PYTHONPATH or PYTHONHOME set? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1292634 ] The _ssl build process for 2.3.5 is broken
Bugs item #1292634, was opened at 2005-09-16 09:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&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: Windows Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Robert Cheung (robertcheung) Assigned to: Nobody/Anonymous (nobody) Summary: The _ssl build process for 2.3.5 is broken Initial Comment: I have attempted to build the _ssl library for 2.3.5 and it is broken (see attached output 1). Basically it is complaining that the _ssl.pyd file could not be build because several symbols (GetUserObjectInformation, etc) could not be linked. Those symbols are suppose to be located in User32.[lib|dll]. Appending User32.lib to line 15 of _ssl.mak fixed this problem (see attachment 2). Hopefully this will be helpful for other people that also had build problems with the ssl library. Regards Robert Cheung Attached output 1-- C:\downloads\python\Python-2.3.5\PCbuild>python build_ssl.py Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at 'C:\downloads\python\openssl-0.9.8' Executing nmake over the ssl makefiles... Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. cl /nologo ../Modules/_ssl.c C:\downloads\python\openssl-0.9.8/out32/libeay32.lib C:\downloads\python\openssl-0.9.8/out32/ssleay32.lib /Ox /MD /LD /Fox86-temp-release/_ssl\_ssl.obj -I ../Include -I ../PC -I C:\downloads\python\openssl-0.9.8/inc32 /link /out:_ssl.pyd gdi32.lib wsock32.lib /libpath:C:\downloads\p ython\openssl-0.9.8/out32 libeay32.lib ssleay32.lib _ssl.c Creating library _ssl.lib and object _ssl.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_showfatal _ssl.pyd : fatal error LNK1120: 4 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Attachment 2 - _ssl.mak line 15 - LIBS=gdi32.lib wsock32.lib /libpath:$(SSL_LIB_DIR) libeay32.lib ssleay32.lib User32.lib -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 12:07 Message: Logged In: YES user_id=21627 Closing as invalid. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:38 Message: Logged In: YES user_id=21627 You are using an unsupported version of OpenSSL. Please try the version mentioned in PCbuild/readme.txt. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1316162 ] Segmentation fault with invalid "coding"
Bugs item #1316162, was opened at 2005-10-07 22:24
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 7
Submitted By: Humberto Diógenes (virtualspirit)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: Segmentation fault with invalid "coding"
Initial Comment:
Reproducing the bug:
1. Create a file with a invalid encoding such as:
# -*- coding: utf-8i -*-
2. Run it:
python wrong_coding.py
3. Enjoy your segfault... :P
Versions tested:
- Python 2.4.2 (Ubuntu Breezy)
- Python 2.3.5 (Debian Sarge)
Running it directly with "python -c" gives MemoryError. Strace output:
# strace python -c "# -*- coding: utf-8i -*-"
(lots of searching through modules...)
open("/usr/lib/python2.3/site-packages/ZopePageTemplates/utf_8i.
pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(2, "MemoryError", 11MemoryError) = 11
write(2, "\n", 1
) = 1
rt_sigaction(SIGINT, NULL, {0x400297a0, [], SA_RESTORER,
0x400c16f8}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
exit_group(1) = ?
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-08 18:23
Message:
Logged In: YES
user_id=1188172
You're right, I hadn't updated my CVS lately.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-08 09:21
Message:
Logged In: YES
user_id=33168
Are you sure you can reproduce with 2.4 CVS branch. I just
fixed this recently (Fix segfault with invalid coding. in
Misc/NEWS). I can't reproduce on 2.4 CVS. I expect this
probem exists in 2.4.2 and earlier. Checked in around
2005/10/02 at 01:48:49, bug #772896.
The memory error was fixed in CVS, but not backported.
That's up to Anthony (release manager).
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-08 08:24
Message:
Logged In: YES
user_id=1188172
Reproducable here with 2.4.2 and the 2.4 CVS branch. It
seems fixed in HEAD.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316162&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
