[ python-Bugs-1168427 ] Possible windows+python bug
Bugs item #1168427, was opened at 2005-03-22 16:38
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=1168427&group_id=5470
Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug
Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer :
5_1_2600) with Python2.3 installed.
Start Python and type (of course x.x.x.x should be
replaced with IP address):
import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))
Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.
By the way, IP protocol 0x04 is "IP over IP", and I
could send such datagrams month ago with Python
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or
it could be due to some driver (BCCode: d1 is specific
for drivers related problems). It needs further
testing on different configurations.
Note that the problem doesn't appears when string in
sendto() function is not empty.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-19 16:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: Brett Cannon (bcannon) Date: 2005-03-22 12:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1003195 ] segfault when running smtplib example
Bugs item #1003195, was opened at 2004-08-04 08:43 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt -- Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-12-27 07:30 Message: Logged In: YES user_id=1097255 > I'll close this bug as "Won't fix". I think that's OK. -- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 19:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-08-08 04:14 Message: Logged In: YES user_id=1097255 Indeed, I did compile python 2.2.1 with Gcc versions 2.95, 3.0 and 3.3. The segfault only occurs in the 2.95 compiled code. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 11:30 Message: Logged In: YES user_id=580910 I cannot reproduce this. I've tested: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] on linux2 The first is the system python on MacOS X, the other two are current Debian packages (python2.3 and python2.2) on Debian stable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-779388 ] sgmllib incorrectly handles entities in attributes
Bugs item #779388, was opened at 2003-07-29 02:43
Message generated for change (Settings changed) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470
Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Misha Bergal (mbergal)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib incorrectly handles entities in attributes
Initial Comment:
The following test inserted in test_sgmllib.py fails
def test_entities_in_attrs(self):
"""Be sure quotes entities are treated right
attributes"""
self.check_events("", [
("starttag", "a", [("href",
'&')]),
])
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 18:05
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-12-26 18:57
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-608635 ] Unix popen does not return exit status
Bugs item #608635, was opened at 2002-09-12 19:03 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Thomas Wouters (twouters) Summary: Unix popen does not return exit status Initial Comment: The documentation for os.popen[234] states that the close will return the rc of the process. This works well on windows, but the unix code does not work, None is returned. The attached version of popen2.py fixes the problem by wrapping the fromchild fd with an object that implements the documented close() behaviour. I have also extended the test() to cover testing the rc and run on FreeBSD against 2.2.1 -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 18:23 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Barry Alan Scott (barry-scott) Date: 2002-09-16 19:15 Message: Logged In: YES user_id=28665 I don't care how this is fixed. I just want a fix. It would be nice if any fix can make it into a 2.2.x maint release rather then wait for 2.3. If you also think this way then exploiting 2.3 features is not reasonable. Which version should I diff against to make a patch? On the specific points: Why not return -1? The -1 is the value set that means no status available. (See sts variable - not sure how this works as a class variable!) This will be the case if you close the fd before the process exits. Windows version seems to return None in cases where the exit code is not available. But I've not read the code to find out details. A suppose a __get__() would allow forwarding of gets to all of the fd's properties. I may be worth copying the functions from the fd to the wrapper for speed. Note: fd.close() returns None not zero. I was hoping whoever designed the API could comment on how they though it should work. -- Comment By: Oren Tirosh (orenti) Date: 2002-09-16 09:29 Message: Logged In: YES user_id=562624 It seems that Taral has beat me to it. http://python.org/sf/608182 "Enhanced file constructor" This patch would make it possible to implement popen as a subclass of file. -- Comment By: Oren Tirosh (orenti) Date: 2002-09-16 04:41 Message: Logged In: YES user_id=562624 I think I have a cleaner solution than a wrapper object. Now that we can inherit from built-in types it should be possible to make a subclass of file and override the close method. There's a small problem because file.__new__ returns an uninitialized file object and there is no way to initialize it in Python, only from C. I noticed this a while ago but now that I see an actual use for subclassing file objects I think it's time to fix it. Patch coming soon. -- Comment By: Thomas Wouters (twouters) Date: 2002-09-13 06:12 Message: Logged In: YES user_id=34209 Hm, for some reason I thought the C 'close()' function (and os.close()) did return the status. They don't, it should be 'pclose()'. os.popen() passes this as the 'close' function to the file constructor, so the rest of the statements still stand :) -- Comment By: Thomas Wouters (twouters) Date: 2002-09-13 06:03 Message: Logged In: YES user_id=34209 Assigned to me because I'm last in the 'assigned to' select box. - Points off because you didn't upload a patch, you uploaded a new version. I think I diff'ed against the right version, but a patch is much better. - I'm not happy with the selective copying of attributes to the wrapper object. For example, you aren't copying xreadlines -- and what else ? Copying all 'public' attributes (those not starting with _) seems a much safer bet. - The test is wrong; you mean 'exit 6', not 'return 6'; return might work in some shells, but it isn't the correct way and it doesn't work in bash, at least. I'm also not sure how portable this is; howmany platforms us
[ python-Bugs-608033 ] Implied __init__.py not copied
Bugs item #608033, was opened at 2002-09-11 17:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 Category: Distutils Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: A.M. Kuchling (akuchling) Summary: Implied __init__.py not copied Initial Comment: The setup method in distutils won't allow me to specify packages and py_modules, and it doesn't correctly deduce all of the directories that need __init__.py files copied. See the attached setup.py for an example. This setup.py is automatically generated from a cca.sidl file containing an interface description. In my example, the directory structure is as follows: gov/ gov/cca/ gov/cca/ports/ decaf/ decaf/ports The problem is that gov/ only contains __init__.py. If I specific packages and py_modules in my setup call, I see the following: [EMAIL PROTECTED] runPython]$ python2.2 setup.py --include-dirs=`cd ../../../runtime/python && pwd` --include-dirs=`cd ../../../runtime/sidl && pwd` --include-dirs=`cd . && pwd` --library-dirs=`cd ../../../runtime/sidl/.libs && pwd` install --prefix=/tmp/pytest running install running build running build_py error: build_py: supplying both 'packages' and 'py_modules' options is not allowed [EMAIL PROTECTED] runPython]$ If I comment out the "packages = []" part and do a "python setup.py install", it doesn't copy gov/__init__.py, decaf/__init__.py and decaf/ports/__init__.py to the installation directory. >From this data, it appears that distutils isn't deducing the package list correctly from py_modules and ext_modules. For each element of py_modules, it should add all the parent modules. For an py_modules entry, a.b.c.d.e.f, distutils should add a, a.b, a.b.c, a.b.c.d, and a.b.c.d.e to the package list. distutils should also glean package names from the ext_modules list. -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 18:25 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-12-01 20:56 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 12:01 Message: Logged In: YES user_id=11375 Actually, it looks like there's code in build_py.py that does add the __init__.py file; see the find_modules() method. It must be broken in some way. I'll look into it. -- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 14:28 Message: Logged In: YES user_id=94539 I can fix my particular problem by using packages and not py_modules. -- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 14:19 Message: Logged In: YES user_id=94539 I read the section loewis linked me to, and the example given there has 'mod1' in the "root package" and "pkg.mod2" in the pkg/ package. This leads me to believe that py_modules do not go into a single package as loewis suggests. In addition, distutils should copy __init__.py files implied by the list of C extension modules. -- Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 04:04 Message: Logged In: YES user_id=21627 It appears that you are misunderstanding the meaning of the py_modules argument. See http://www.python.org/doc/current/dist/setup-script.html#SECTION00032 It says "specially the case of a single module that goes in the ``root package'' " All py_modules modules are in a single package, irrespective of their source location. -- Comment By: Tom Epperly (tepperly) Date: 2002-09-11 17:22 Message: Logged In: YES user_id=94539 I am surprised that sourceforge let me assign this to someone. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-20 00:14 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: John Ehresman (jpe) Date: 2005-03-22 21:37 Message: Logged In: YES user_id=22785 The issue seems to be that in symtable_analyze, a free dictionary is created for the entire module and if a name is found to be free in any function, it is not converted from a LOCAL to a CELL is any context seen afterwards. I think the free variables need to be recorded on a function-by-function basis. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-22 20:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8
Bugs item #602627, was opened at 2002-08-30 17:51 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, lo
[ python-Bugs-487471 ] urllib2 proxyhandle won't work.
Bugs item #487471, was opened at 2001-11-30 07:54 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. -- Comment By: Jim Jewett (jimjjewett) Date: 2005-03-22 17:04 Message: Logged In: YES user_id=764593 As John J. Lee said, it is fixed now. The fix was in 1.48, which was apparently included with python 2.3beta2 - and therefore the problem doesn't occur. That said, there is an XXX comment added in 1.57 asking # XXX why does self.handlers need to be sorted? and if they aren't sorted, then the issue will recur in some but not all tests. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 17:32 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 18:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: John J Lee (jjlee) Date: 2003-10-30 14:02 Message: Logged In: YES user_id=261020 That last comment was from me (cookie problems, ironically). -- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-30 13:57 Message: Logged In: NO This should be closed. I don't recall which minor version of 2.2 this was introduced at, but there's no need to replace build_opener any more. The most you have to do is to explicitly pass a handler or two to build_opener with appropriately set handler_order attributes. Or you can subclass the handlers. -- Comment By: Micah Stetson (micahs) Date: 2003-05-07 19:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 16:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? -- Comment By: Ha Shao (hashao) Date: 2001-11-30 08:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-591287 ] makesetup fails: long Setup.local lines
Bugs item #591287, was opened at 2002-08-05 17:25 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 Category: Build Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Sam Tannous (stannous) Assigned to: Nobody/Anonymous (nobody) Summary: makesetup fails: long Setup.local lines Initial Comment: makesetup fails: long Setup.local lines. I've included an attachment that describes the problem. Thanks, Sam Tannous (employees.org) -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 19:05 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:18 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 11:29 Message: Logged In: YES user_id=11375 It's not length; it's the '=' symbol. Modules/makesetup compares the line to '*=*', and if it matches, assumes it's a definition, like 'DESTLIB=foo'. That also matches your -DBYTE_ORDER=1234, though, so makesetup just copies the line verbatim into the definition section. I don't see how to fix it, though; shell pattern matching doesn't seem powerful enough to do something like [^ ]*=*. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-591104 ] os.tmpfile() can fail on win32
Bugs item #591104, was opened at 2002-08-05 11:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470 Category: Windows Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Joseph Barillari (jdbarillari) Assigned to: Mark Hammond (mhammond) Summary: os.tmpfile() can fail on win32 Initial Comment: I've discovered what appears to be a bug in Python 2.2.1 on Win32. I'm using the 2.2.1 build that I downloaded from python.org. I'm running Windows 2000. If os.tmpfile() is exceuted when the CWD is a UNC path, the base of which is not writeable by the current user, tmpfile will fail. tempfile.TemporaryFile will work, so I suspect this is a bug in os.tmpfile(). For example: C:\>pwd /cygdrive/c #I use cygwin C:\>bash# I have to use bash; the DOS shell doesn't support UNC paths bash: .bashrc: No such file or directory bash-2.05a$ cd //bopp/jbarilla bash-2.05a$ pwd //bopp/jbarilla bash-2.05a$ python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile()', mode 'w+' at 0x007762C0> # It works. >>> ^Z If I chmod 555 //bopp/jbarilla (from unix via NFS; incidentally, "chmod 555 ." from cygwin is ineffectual), then tmpfile fails: bash-2.05a$ pwd //bopp/jbarilla bash-2.05a$ python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile() Traceback (most recent call last): File " ", line 1, in ? OSError: [Errno 13] Permission denied # Oops. # However, tempfile.TemporaryFile works: >>> import tempfile; tempfile.TemporaryFile() --Joe -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 19:06 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:13 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Jonathan Simms (slyphon) Date: 2002-08-10 03:21 Message: Logged In: YES user_id=404786 Hi, I'm a bit new here, but I'd like to help... This like a cygwin issue. I've been using cygwin as a development environment for about a year, and nothing has driven me more crazy than the consistent problems converting between unc and win32 paths. There's the cygpath utility that you can put to use, it'll convert posix to win32 paths and vice-versa. Also, if you want to use chmod and unix-style permissions with cygwin, you need to make sure that the $CYGWIN variable has been set to include 'ntsec'. related to the cygwin environment variable: http://cygwin.com/cygwin-ug-net/using-cygwinenv.html ...This advice comes with no warranty, and I apologise if I'm mistakenly off-the-mark... Cheers --Jonathan -- Comment By: Joseph Barillari (jdbarillari) Date: 2002-08-06 11:40 Message: Logged In: YES user_id=589825 \quote{BTW, do you really think this has something to do with UNC paths? From what you said it seems to be a matter of having sufficient permission to scribble in the current directory.} Oops. You're right: Z:\>touch a touch: creating `a': Permission denied Z:\>python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile() Traceback (most recent call last): File " ", line 1, in ? OSError: [Errno 13] Permission denied >>> -- Comment By: Tim Peters (tim_one) Date: 2002-08-06 00:19 Message: Logged In: YES user_id=31435 Assigned to Mark in case he has another idea, but I think you're out of luck. os.tmpfile() does nothing except call Microsoft's tmpfile() function, and that doesn't allow specifying a directory. If you don't have permission to create a file in the current directory, you lose, and Python's behavior here will change when Microsoft's does. tempfile.TemporaryFile() "simulates" a temp file via other means, and can control which directory it uses. BTW, do you really think this has som
[ python-Bugs-579116 ] pthread_exit missing in thread_pthread.h
Bugs item #579116, was opened at 2002-07-09 10:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 Category: Threads Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michael Pronath (micpro) Assigned to: Nobody/Anonymous (nobody) Summary: pthread_exit missing in thread_pthread.h Initial Comment: I'm using the Python 2.2.1 interpreter for scripting language in a larger program. When I used the threading module to create new threads, my main program did not exit anymore, but hang, because one python thread always remained. It got much better when I inserted a call to pthread_exit into do_PyThread_exit_thread (thread_pthread.h). Patchfile is attached. -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 19:07 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:11 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Valeriy Pogrebitskiy (vpogrebi) Date: 2003-11-06 11:55 Message: Logged In: YES user_id=902722 I'm using Python 2.2.1 (Unix) in a daemon process that starts child threads to handle specific events. I have noticed that occasionally (not all the time) child thread "stays" (in a SLEEPING) status after thread exits. When this happens, that thread never exits until entire process is stopped. I have log files that have output coming from threading module (I have set threading._VERBOSE to 1) that show each thread's start and termination events. In addition, I use Queue module for inter-thread communication (when thread starts execution, it posts "START" message, and when it is about to exit its run() method, it posts "END" event). So, from these logs and from output of "ps -fp- o 'user,pid,ppid,pgid,time,stime,lwp,s'" I can see that some threads exit (which is indicated by _VERBOSE output and a message in a Queue), but still stay (in a SLEEPING state) in the process. Does this behavior have something to do with the problem described in this report, or is it something different? Is there patch (full instalation package) that fixes this problem (without me having to update source code and recompile the executable)? -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 22:08 Message: Logged In: YES user_id=33168 Michael do you still have this problem with 2.2.2 or do you still require this patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-569316 ] cgi.py broken with xmlrpclib on Python 2
Bugs item #569316, was opened at 2002-06-15 05:53
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470
Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Pike (oztourer)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py broken with xmlrpclib on Python 2
Initial Comment:
Given a web application which accepts both normal
HTTP requests and XML-RPC requests, it is
reasonable for that program to assume it can create a
cgi.FieldStorage instance in either case. This works
fine in Python 1.5.2 but causes exceptions in Python
2.x.x when using the created FieldStorage. This is due
to the content-type header generated by xmlrpclib.py
('text/xml') being unrecognised in cgi.py, as a result of
which no FieldStorage.list is created.
One solution is to reinstate some code in cgi.py from
the 1.5.2 release, at the end of method __init__, after
removing the current final two lines:
#else:
#self.read_single()
# SP 2002/6/15: The following code is taken
from the Python 1.5.2 version
# of cgi.py, as incoming xmlrpclib requests
otherwise do not cause 'list'
# to be set up correctly.
elif self.outerboundary:
# we're in an inner part, but the content-type
wasn't something we
# understood. default to read_single()
because the resulting
# FieldStorage won't be a mapping (and
doesn't need to be).
self.read_single()
else:
# we're in an outer part, but the content-type
wasn't something we
# understood. we still want the resulting
FieldStorage to be a
# mapping, so parse it as if it were urlencoded
self.read_urlencoded()
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:09
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-30 23:08
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-566037 ] Popen exectuion blocking w/threads
Bugs item #566037, was opened at 2002-06-07 21:07
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470
Category: Threads
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads
Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0
import os, threading,time, sys
def read_output(self, cmd, timeout):
print "run: %s" % cmd
(inf,outf) = os.popen4(cmd)
print "started! out_fd=%d" % outf.fileno()
while 1:
line = outf.readline()
if line == "": break
print len(line),line
sys.stdout.flush()
return
if __name__ == '__main__':
thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
thr.start()
print "Started thread"
while 1: time.sleep(1)
[EMAIL PROTECTED](3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
libdl.so.2 => /lib/libdl.so.2 (0x4004)
libutil.so.1 => /lib/libutil.so.1 (0x40044000)
libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
libm.so.6 => /lib/libm.so.6 (0x4008f000)
libc.so.6 => /lib/libc.so.6 (0x400b1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
/usr/local/bin/python2.2:
libdl.so.2 => /lib/libdl.so.2 (0x40029000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
libutil.so.1 => /lib/libutil.so.1 (0x40044000)
libm.so.6 => /lib/libm.so.6 (0x40047000)
libc.so.6 => /lib/libc.so.6 (0x4006a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-03-22 19:11
Message:
Logged In: YES
user_id=752496
Deprecated. Reopen only if still happens in 2.3 or newer.
.Facundo
--
Comment By: Martin Stoufer (mstoufer)
Date: 2004-11-30 12:18
Message:
Logged In: YES
user_id=133905
I have not worked on this bug since I submitted it and have
since gone onto a more saner software model. This bug may be
closed or assigned to someone else to follow up on.
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-29 20:28
Message:
Logged In: YES
user_id=752496
Works fine in Py2.3.3, Fedora Core 2.
--
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-29 20:28
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Becky Burwell (burwell)
Date: 2002-10-04 19:01
Message:
Logged In: YES
user_id=348250
FYI: this happens if the program is a bash shell which calls
ping.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-10-04 18:20
Message:
Logged In: YES
user_id=6380
I can reproduce this in Python 2.3, by the way. I'm just not
sure that there's anything that Python can do to avoid this
-- it feels like a bug in libc (or in ping).
Lowering priority because of that.
--
Comment By: Becky Burwell (burwell)
Date: 2002-10-04 17:53
Message:
Logged In: YES
user_id=348250
We have the same problem in RedHat 7.3 with Python 2.2
using ping in a thread. If I do a popen or just os.system in a
thread, the ping hangs for hosts that are not responding
(works fine IF the host is up.)
Note: this code works fine in Python 2.1.1 and works fine not
in a thread in Python 2.2
Also: if the command prints out lots of output there is still a
hang.
The ping command has to be killed with a kill -9.
#!/usr/bin/python2
import os,threading
class MyHost(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
def run(self):
ping_string = "/bin/ping -q -c 1 -w 2 hostthatisdown"
print "about to execute ping string %s\n" % ping_string
f = os.popen (ping_string,"r")
result = f.close ()
print "result is ",res
[ python-Bugs-530163 ] fpectl build on solaris: -lsunmath
Bugs item #530163, was opened at 2002-03-15 00:47 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470 Category: Build Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: fpectl build on solaris: -lsunmath Initial Comment: This is on Solaris 2.7, with gcc2.95.2 Observed on both the trunk and the release22 branch. By default, the configure/setup stuff isn't including -L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath when linking fpectl.so. This means that this doesn't produce a working module (it needs libsunmath for ieee_handler) My autoconf knowledge isn't excellent, but I'm going to have a look-see, figure out the easiest way to do this... -- Comment By: Facundo Batista (facundobatista) Date: 2005-03-22 19:14 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2004-11-29 20:14 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2002-03-15 06:22 Message: Logged In: YES user_id=21627 I think there is absolutely no way to find SUNWspro reliably. /opt is but one location where it might be installed - on our infrastructure, it is not in /opt, since that is not NFS shared. If c89 is on the path, it could give an indication where SUNWspro may be installed. In any case, I recommend to perform the necessary computation in setup.py, not in autoconf. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166274 ] missing sequence tests - pull from deque
Bugs item #1166274, was opened at 2005-03-18 23:21 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Walter Dörwald (doerwalter) Summary: missing sequence tests - pull from deque Initial Comment: tuples and lists can be initialized from any sequence, including an iterator. This is not tested. The iterator tests in test_deque would do a good job. list_tests (for list and UserList) test_remove does not test that it is the _first_ occurence that gets removed. Again, the deque tests that Raymond just checked in are up to the job, if "deque" is replaced by "type2test" -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-03-22 23:45 Message: Logged In: YES user_id=89016 Checked in the "construct from iterable" tests as: Lib/test/seq_tests.py 1.4 Lib/test/test_deque.py 1.22 I've moved the iterables from test_deque to seq_tests, so that they can be reused. Closing the report. Thanks for the tip! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-03-21 22:33 Message: Logged In: YES user_id=89016 Checked in the remove test as: Lib/test/list_tests.py 1.6 (Note that I've dropped the evil mutator test, because it doesn't raise an exception). I'll add the iterator initialization test tomorrow. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166274&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1168746 ] frame.f_exc_type,value,traceback
Bugs item #1168746, was opened at 2005-03-22 23:07 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=1168746&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 4 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: frame.f_exc_type,value,traceback Initial Comment: The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are misdocumented. They are not the last exception caught by the frame, nor the one currently handled, or anything reasonable like that. They give the last exception raised in the parent frame, and only if another exception was ever raised in the current frame (in all other cases they are None). I very much doubt this is useful to anyone, so maybe un-publishing the attributes would be sensible, but in any case the doc needs a small fix (ref/types.html and the doc about and in inspect.py). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-20 00:14 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: John Ehresman (jpe) Date: 2005-03-23 01:21 Message: Logged In: YES user_id=22785 The attached patch seems to fix this by creating a dictionary for each scope's free vars and only propagating up the ones that aren't satisfied by a binding. With this and the other patches, the test suite runs w/o segfaulting up through test_unicode. -- Comment By: John Ehresman (jpe) Date: 2005-03-22 21:37 Message: Logged In: YES user_id=22785 The issue seems to be that in symtable_analyze, a free dictionary is created for the entire module and if a name is found to be free in any function, it is not converted from a LOCAL to a CELL is any context seen afterwards. I think the free variables need to be recorded on a function-by-function basis. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-22 20:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py
Bugs item #1166714, was opened at 2005-03-20 00:14 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Brett Cannon (bcannon) Summary: [ast branch] fatal error when compiling test_bool.py Initial Comment: When using the ast-branch compiler, python exits with a fatal error when compiling test_bool.py or the symplified test case that I'll attach. The immediate problem is that when the compiler is in make_closure after compiling the lambda, self is found to be a LOCAL reference type and make_closure assumes it's a FREE reference if it's not a CELL reference in the enclosing scope. I don't know if self is supposed to be a LOCAL reference or if make_closure should handle LOCAL references. -- >Comment By: John Ehresman (jpe) Date: 2005-03-23 01:22 Message: Logged In: YES user_id=22785 Forgot to add the patch -- Comment By: John Ehresman (jpe) Date: 2005-03-23 01:21 Message: Logged In: YES user_id=22785 The attached patch seems to fix this by creating a dictionary for each scope's free vars and only propagating up the ones that aren't satisfied by a binding. With this and the other patches, the test suite runs w/o segfaulting up through test_unicode. -- Comment By: John Ehresman (jpe) Date: 2005-03-22 21:37 Message: Logged In: YES user_id=22785 The issue seems to be that in symtable_analyze, a free dictionary is created for the entire module and if a name is found to be free in any function, it is not converted from a LOCAL to a CELL is any context seen afterwards. I think the free variables need to be recorded on a function-by-function basis. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-22 20:34 Message: Logged In: YES user_id=357491 An short example of the failure:: def outer(a): def first(): a def last(a): pass This leads to a fatal Python error. The issue is having a being a local or parameter (can make 'a' be 'a = 1' and not a parameter and still have it fail), the first closure reference it, and then the second one use it as a parameter. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1166714&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
