[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler
Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 00:30
Message:
Logged In: YES
user_id=33168
The tuple store problem is fixed. The only outstanding item
is the LOAD_CONST/POP_TOP. I will fix that soon.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 22:56
Message:
Logged In: YES
user_id=33168
Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10. The last two by Armin,
Michael, then my last comment are the only important ones.
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.
--
Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54
Message:
Logged In: YES
user_id=4771
Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value! See:
>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !
I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node. If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.
--
Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02
Message:
Logged In: YES
user_id=6656
We found another one. Something is wrong in the compilation of augmented
assignment to subscriptions containing tuples; running this code:
class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0
c = C()
c[4,5] += 1
gives a spurious exception:
Traceback (most recent call last):
File "", line 1, in
TypeError: object does not support item assignment
By contrast, "c[(4,5)] += 1" works fine.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10
Message:
Logged In: YES
user_id=33168
EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.
That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.
--
Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41
Message:
Logged In: YES
user_id=6656
You have to include those lines in a source file. It still crashes for me.
--
Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44
Message:
Logged In: YES
user_id=357491
I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter. You still having
problems, Armin?
--
Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30
Message:
Logged In: YES
user_id=4771
At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed
---
assert 1, ([s for s in x] +
[s for s in x])
pass
---
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14
Message:
Logged In: YES
user_id=33168
Checkpoint of outstanding issues. I think all the others
mentioned so far have been fixed:
* Raymond's warnings in compile.c (unused locals are fixed)
* EXTENDED_ARG problem
* LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53
Message:
Logged In: YES
user_id=80475
FWIW, here are the warnings issued by my compiler:
Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warn
[ python-Bugs-1421664 ] [win32] stderr atty encoding not set
Bugs item #1421664, was opened at 2006-02-01 18:25
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&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.4
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Snaury (snaury)
Assigned to: Martin v. Löwis (loewis)
Summary: [win32] stderr atty encoding not set
Initial Comment:
When starting python console application under windows,
output of unicode strings to console fails because of
ansi encoding. I found that in file
Python-2.4.2/Python/sysmodule, _PySys_Init functions,
setting encoding on stderr was forgotten:
#ifdef MS_WINDOWS
if(isatty(_fileno(stdin))){
sprintf(buf, "cp%d", GetConsoleCP());
if (!PyFile_SetEncoding(sysin, buf))
return NULL;
}
if(isatty(_fileno(stdout))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(sysout, buf))
return NULL;
}
#endif
I think the following lines should be added:
if(isatty(_fileno(stderr))) {
sprintf(buf, "cp%d", GetConsoleOutputCP());
if (!PyFile_SetEncoding(syserr, buf))
return NULL;
}
Otherwise it's inconsistant, as if we set it to sysout,
why not on syserr? And, for example, this code will not
work properly:
#!/usr/bin/env python
# -*- encoding: mbcs -*-
import sys
reload(sys) # bring setdefaultencoding back!
sys.setdefaultencoding("mbcs")
sys.stderr.write(u"\n")
Instead of native text garbage will be printed (if you
change it to sys.stdout, proper text displayed), and
there is no way I know to properly determine and set
encoding just for stderr (file.encoding is read-only,
after all).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-03 12:57
Message:
Logged In: YES
user_id=21627
Thanks for the report. This is now fixed in #43581.
--
Comment By: Snaury (snaury)
Date: 2006-02-01 18:29
Message:
Logged In: YES
user_id=1197042
Ooops, sorry, in the example it should be:
print >>sys.stderr, u""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421664&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Bugs item #1456470, was opened at 2006-03-22 23:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&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: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Jim Jewett (jimjjewett) Assigned to: Martin v. Löwis (loewis) Summary: sliceobject ssize_t (and index) not completed Initial Comment: sliceobject and ceval changed the parameter types of slice objects to ssize_t, but the code still requires an int (sometimes not even a long); it should use the new __index__ slot; at the very least, it should be consistent about what it does accept. In http://svn.python.org/view/python/trunk/Objects/ sliceobject.c?rev=42382&view=markup [issue 1] function PySlice_GetIndices takes Py_ssize_t parameters for (length, start, stop, step) but then does a PyInt_Check on each of start, stop, step. (An XXX to allow longs was also removed.) It * should* use the new __index__ slot. [issue 2] Later in the same file, function slice_ indices takes a PyObject len parameter, but then uses PyInt_AsLong rather than __index__ (or even PyInt_ AsSsize_t) to create Py_ssize_t ilen. [issue 3] http://svn.python.org/view/python/trunk/Python/ceval.c? rev=42382&view=markup function _PyEval_SliceIndex accepts only ints and longs, and longs will be converted to ints with clipping. It should allow anything with __index__, and clip only to ssize_t rather than int. [issue 4] ISINT still insists on int or long -- I thought I saw a fix for this already in the index patches. [issue 5] apply_slice and assign_slice changed the types of ilow and ihigh, but still initializes them to INT_MAX rather than ssize_t max. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 13:38 Message: Logged In: YES user_id=21627 I believe these are all fixed as of 43583 (and earlier). -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:33 Message: Logged In: YES user_id=21627 Would you like to work on a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1461115 ] test_winsound fails in 2.4.3
Bugs item #1461115, was opened at 2006-03-30 07:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: test_winsound fails in 2.4.3 Initial Comment: The released 2.4.3 Windows installer doesn't include source file Lib/test/check_soundcard.vbs, which causes test_winsound to report 7 bogus failures when run on a box with a sound card. I expect the 2.5 installer also needs to be fiddled to include this file. I confirmed that the problem went away after copying check_soundcard.vbs from a 2.4 branch checkout into the 2.4.3 installation tree. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 14:18 Message: Logged In: YES user_id=21627 Thanks for the report; this was fixed in 43584 and 43585. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&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: Extension Modules Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) >Assigned to: Georg Brandl (gbrandl) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. -- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=143 Sorry, but I can't work on a patch. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 18:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&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: Extension Modules Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) Assigned to: Georg Brandl (gbrandl) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 12:26 Message: Logged In: YES user_id=849994 Rev. 43586. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 12:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 15:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. -- Comment By: roee88 (roee88) Date: 2006-03-22 12:00 Message: Logged In: YES user_id=143 Sorry, but I can't work on a patch. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 10:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445781 ] install fails on hard link
Bugs item #1445781, was opened at 2006-03-08 18:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Martin v. Löwis (loewis) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 14:33 Message: Logged In: YES user_id=21627 If we are going to support "funny" file systems, falling back to copying looks right to me. While Apple's SMB implementation supports symlinks on smb (through a hack), other implementations might not. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:24 Message: Logged In: YES user_id=580910 Adding a -s flag to the link command should also fix this issue and has the advantage that all builds will be done the same way. The cost for resolving the symlink should be neglectible. -- Comment By: goldenautumnday (goldenautumnday) Date: 2006-03-08 21:22 Message: Logged In: YES user_id=1471082 Changing line 599 in Makefile.pre.in to: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python $(VERSION)$(EXE) $(PYTHON)) allowed make to complete. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&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-1451588 ] bisect should support a custom comparison function
Feature Requests item #1451588, was opened at 2006-03-16 19:26 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&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: Jonathan S. Joseph (jsjoseph) Assigned to: Nobody/Anonymous (nobody) Summary: bisect should support a custom comparison function Initial Comment: The 'bisect' module provides functions for finding the proper insertion point of an item in a sorted list. The sort() function for lists supports passing in a custom comparison function, however none of the functions in bisect() support this. The method used by bisect to find the proper insertion point is not documented, but I guess the module relies on a natural ordering for the items, or on the items of the list implementing __cmp__. I suggest adding a 5th argument, with keyword 'cmp', to the functions in the 'bisect' module that would allow supplying a custom comparison function, as for 'sort'. bisect_left(list, item[, lo[, hi]][,cmp]) bisect_right( list, item[, lo[, hi]][,cmp]) bisect(...) insort_left(list, item[, lo[, hi]][,cmp]) insort_right( list, item[, lo[, hi]][,cmp]) insort(...) -- Comment By: Matt Fleming (splitscreen) Date: 2006-04-03 12:57 Message: Logged In: YES user_id=1126061 See patch #1462228. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1451588&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Bugs item #1463043, was opened at 2006-04-02 15:03
Message generated for change (Comment added) made by rptownsend
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Initial Comment:
I built Python-2.4.3 from source on SUSE 9.3 and get
the following error for test_minidom.py
/usr/local/src/Python-2.4.3: ./python
Lib/test/test_minidom.py
Failed Test
Test Failed: testAltNewline
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 427, in
testAltNewline
confirm(domstr == str.replace("\n", "\r\n"))
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed testEncodings - encoding EURO SIGN
Test Failed: testEncodings
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 891, in
testEncodings
"testEncodings - encoding EURO SIGN")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed After replaceChild()
Test Failed: testPatch1094164
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 1137, in
testPatch1094164
confirm(e.parentNode is elem, "After replaceChild()")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed Test
Test Failed: testWriteXML
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 420, in
testWriteXML
confirm(str == domstr)
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Check for failures in these tests:
testAltNewline
testEncodings
testPatch1094164
testWriteXML
--
>Comment By: Richard Townsend (rptownsend)
Date: 2006-04-03 14:37
Message:
Logged In: YES
user_id=200117
Hi Neal,
I've just built 2.4.3 on a Red Hat Enterpeise Edition WS
V4.2 machine and this gives the same error.
I've had this vague feeling that I've seen something like
this before, but couldn't find anything when I searched the
tracker...
I've now realised that the error is due to a conflict with
PyXML-0.8.4 which was already installed on both machines.
If I rename the ../site_packages/_xmlplus directory to a
different name then the error goes away (on the Red Hat
machine at least, the SUSE machine is at home).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 06:37
Message:
Logged In: YES
user_id=33168
Thanks for letting us know about where the regression
occurred. Can you do a little more debugging to try to find
the cause and some ideas about how to fix it?
I'm not sure that any developer runs on a system that
exhibits this error. So it will probably be very difficult
for us to figure it out since we can't reproduce it.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-02 15:28
Message:
Logged In: YES
user_id=200117
I've just retested with earlier versions.
No error with Python-2.4.1
Similar error with Python-2.4.2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463559 ] missing svnversion == configure error
Bugs item #1463559, was opened at 2006-04-04 00:04 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=1463559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: missing svnversion == configure error Initial Comment: Attempting to build the trunk from source on a box without svn installed spits this out of configure: checking for svnversion... no ./configure: line 3616: test: =: unary operator expected We should handle this more gracefully. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-28 03:30 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&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: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 15:31 Message: Logged In: YES user_id=31392 Just wanted to note that I have fixes for the failing tests on my laptop. Need to sync with the current trunk before I can check in. -- Comment By: Brett Cannon (bcannon) Date: 2005-10-25 22:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-24 04:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 18:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-11 04:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 11:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 08:33 Message: Logged In: YES user_id=1038590 Bump
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Comment added) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
>Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 15:44
Message:
Logged In: YES
user_id=31392
The source of the problem is that scoping decisions are made
statically. If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code. The compiler has already
determined that the variable is *not* free in the containing
function. If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.
In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f. It isn't possible to change that static
analysis at runtime using eval or exec.
I agree that the documentation could be clearer here.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 03:46
Message:
Logged In: YES
user_id=593130
" def f(x): eval('x') works as expected and
def f(g): eval('lambda x: g(x)') does not. Why?"
For the same reason
def f(g,s): return eval(s)
f(lambda x: x, 'lambda x: g(x)')(1)
and
def g(x): return lambda: eval('x')
do not 'work'. eval is a builtin C function whose behavior
depends on its arguments (including the somewhat magical
defaulting to globals(), local()) and not on its lexical position.
" Both are evaluated at the same time and use
the same environment to look up their variables."
No, the lambda in your second example introduces a new local
namespace that is different from the one passed in.
" The fact that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping"
The delay and change of scoping are correlated. Evaluation is
delayed because g is inside a lambda function def which
introduces a new local scope which does not contain g, even
though the original one did.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 02:55
Message:
Logged In: YES
user_id=593130
After more carefully reading the eval doc in Lib Ref 2.1, I agree
that it needs improvement. My suggestions (assuming that my
experiment-based inferences are correct):
In
"The expression argument is parsed and evaluated as a Python
expression (technically speaking, a condition list) using the
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says
right-off, even if indirectly, that lexical scoping does not work
across the eval call.
In
"If the locals dictionary is omitted it defaults to the globals
dictionary."
insert "only" after "If'. If both are omitted, it does not so default.
Add a comma after 'omitted', as in the next sentence.
In
"If both dictionaries are omitted, the expression is executed in
the environment where eval is called."
replace "the expression ... is called", which I believe to be
incorrect as well as misleading, with something like "they default
to current globals() and locals()." This parallels the previous
sentence and is, I believe, more correct. Within a function,
locals() is not the current local namespace, and the following
shows that the difference can make a visible difference:
>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
File "", line 1, in ?
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 16:48
Message generated for change (Settings changed) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&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: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Mattias Engdegård (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 15:44
Message:
Logged In: YES
user_id=31392
The source of the problem is that scoping decisions are made
statically. If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code. The compiler has already
determined that the variable is *not* free in the containing
function. If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.
In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f. It isn't possible to change that static
analysis at runtime using eval or exec.
I agree that the documentation could be clearer here.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 03:46
Message:
Logged In: YES
user_id=593130
" def f(x): eval('x') works as expected and
def f(g): eval('lambda x: g(x)') does not. Why?"
For the same reason
def f(g,s): return eval(s)
f(lambda x: x, 'lambda x: g(x)')(1)
and
def g(x): return lambda: eval('x')
do not 'work'. eval is a builtin C function whose behavior
depends on its arguments (including the somewhat magical
defaulting to globals(), local()) and not on its lexical position.
" Both are evaluated at the same time and use
the same environment to look up their variables."
No, the lambda in your second example introduces a new local
namespace that is different from the one passed in.
" The fact that the 'g' variable in the second case is not evaluated
immediately does not affect its scoping"
The delay and change of scoping are correlated. Evaluation is
delayed because g is inside a lambda function def which
introduces a new local scope which does not contain g, even
though the original one did.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 02:55
Message:
Logged In: YES
user_id=593130
After more carefully reading the eval doc in Lib Ref 2.1, I agree
that it needs improvement. My suggestions (assuming that my
experiment-based inferences are correct):
In
"The expression argument is parsed and evaluated as a Python
expression (technically speaking, a condition list) using the
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says
right-off, even if indirectly, that lexical scoping does not work
across the eval call.
In
"If the locals dictionary is omitted it defaults to the globals
dictionary."
insert "only" after "If'. If both are omitted, it does not so default.
Add a comma after 'omitted', as in the next sentence.
In
"If both dictionaries are omitted, the expression is executed in
the environment where eval is called."
replace "the expression ... is called", which I believe to be
incorrect as well as misleading, with something like "they default
to current globals() and locals()." This parallels the previous
sentence and is, I believe, more correct. Within a function,
locals() is not the current local namespace, and the following
shows that the difference can make a visible difference:
>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
File "", line 1, i
[ python-Bugs-1431582 ] long path support in win32 part of os.listdir(posixmodule.c)
Bugs item #1431582, was opened at 2006-02-14 16:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&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: 7 Submitted By: Sergey Dorofeev (fidoman) Assigned to: Martin v. Löwis (loewis) Summary: long path support in win32 part of os.listdir(posixmodule.c) Initial Comment: When passing path to os.listdir that is longer then MAX_PATH (what is supported in Windows API, http://msdn.microsoft.com/library/default.asp? url=/library/en-us/fileio/fs/naming_a_file.asp) the path is truncated at position MAX_PATH=260 and appended with "/*.*", so underlying Windows API function FindFirstFileW gets garbage on input: original path truncated, and symbol "/" is added, which may not be used as path separator in long path. I think posix_listdir should or raise error when getting extra long string, or pass it unchanged to underlying API. Affected code is in Modules\posixmodule.c, lines 1470- 1478 (Python 2.4.2). I think there is enough to change base when calculating size of allocated memory and copied block from fixed value of MAX_PATH to length of passed to function string. And use os.sep instead of "/", of course. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&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: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mattias Engdegård (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
>Comment By: Mattias Engdegård (yorick)
Date: 2006-04-03 19:12
Message:
Logged In: YES
user_id=432579
>The source of the problem is that scoping decisions are made
>statically.
No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:
Q: In what environment is the eval() argument evaluated?
typically in one of three ways:
A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.
Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.
Observe that none of the answers depend on what the
expression looks like.
Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions
1) x
and
2) lambda: x
should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.
In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.
Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:
A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.
This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 17:44
Message:
Logged In: YES
user_id=31392
The source of the problem is that scoping decisions are made
statically. If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code. The compiler has already
determined that the variable is *not* free in the containing
function. If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.
In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f. It isn't possible to change that static
analysis at runtime using eval or exec.
I agree that the documentation could be clearer here.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-04 04:46
Message:
Logged In: YES
user_id=593130
" def f(x): eval('x') works as expected and
def f(g): eval('lambda x: g(x)') does not. Why?"
For the same reason
def f(g,s): return eval(s)
f(lambda x: x, 'lambda x: g(x)')(1)
and
def g(x): return lambda: eval('x')
do not 'work'. eval is a builtin C function whose behavior
depends on its
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Comment added) made by yorick
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&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: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Mattias Engdegård (yorick)
Assigned to: Jeremy Hylton (jhylton)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
>Comment By: Mattias Engdegård (yorick)
Date: 2006-04-03 19:36
Message:
Logged In: YES
user_id=432579
Lest my last comment be interpreted as overly arrogant,
please be assured that it was not meant as anything other
than an explanation of why I reported this as a bug in the
first place. I do understand that Python works the way it
does; I just want it to be even better. :-)
--
Comment By: Mattias Engdegård (yorick)
Date: 2006-04-03 19:12
Message:
Logged In: YES
user_id=432579
>The source of the problem is that scoping decisions are made
>statically.
No, because other languages with lexical scope and
permitting evaluation at runtime have no problem whatsoever
with this. They just answer the question:
Q: In what environment is the eval() argument evaluated?
typically in one of three ways:
A1. In an empty environment with no bindings at all, or just
the language-defined standard bindings.
A2. In the (or a) top-level environment; local, lexically
bound variables where the eval() takes place are not visible
to the argument expression.
A3. In the same lexical environment as the eval() call itself.
Perl and Ruby both say A3. Scheme (R5RS) lets the user
specify A1 or A2. Common Lisp answers A2.
Observe that none of the answers depend on what the
expression looks like.
Now, let's be crystal clear about this: The rules of where x
is looked up in the expressions
1) x
and
2) lambda: x
should reasonably be the same - after all, this is
fundamentally how lexical scoping works. And Python does
indeed work this way, to everybody's satisfaction.
In case 2), the evaluation of x is delayed, but that is
irrelevant; the decision of what x means is taken at the
same time in both cases, and the decision will be the same.
Most people would expect Python to answer question Q above
with one of the answers A1-3, but it does not, and it does
not document what the answer is. The Python answer is rather:
A4. A mixed hybrid environment of some kind: The identifiers
representing variables that are to be evaluated immediately
are looked up in the lexical environment of the eval
expression; identifiers representing variables in
delayed-evaluation positions use the global environment.
This answer is not very satisfactory and I'm inclined to
consider a design bug; it is different from what everyone
else does and not very intuitive. However, I can accept that
it is hard to change now for compatibility reasons. But this
answer A4 should be documented.
--
Comment By: Jeremy Hylton (jhylton)
Date: 2006-04-03 17:44
Message:
Logged In: YES
user_id=31392
The source of the problem is that scoping decisions are made
statically. If a variable is determined to be local at
compile time, it can't be access as a free variable in
dynamically compiled code. The compiler has already
determined that the variable is *not* free in the containing
function. If a variable is free in a nested function, the
compiler treats it differently than if it is merely local to
the function.
In the most recent cases considered,
def f(x): eval('x') -- works because x is a local variable in f.
def f(g): eval('lambda x: g(x)') -- does not work because
the compiler has determined that g is not used a free
variable in f. It isn't possible to change that static
analysis at runtime using eval or exec.
I agree that the documentation could be clearer here.
---
[ python-Bugs-1461115 ] test_winsound fails in 2.4.3
Bugs item #1461115, was opened at 2006-03-30 00:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: test_winsound fails in 2.4.3 Initial Comment: The released 2.4.3 Windows installer doesn't include source file Lib/test/check_soundcard.vbs, which causes test_winsound to report 7 bogus failures when run on a box with a sound card. I expect the 2.5 installer also needs to be fiddled to include this file. I confirmed that the problem went away after copying check_soundcard.vbs from a 2.4 branch checkout into the 2.4.3 installation tree. -- >Comment By: Tim Peters (tim_one) Date: 2006-04-03 14:32 Message: Logged In: YES user_id=31435 Thanks, Martin! I wasn't exactly sure what to do, but saw your checkin and see that you did what I guessed should be done -- next time I can do it myself ;-) -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 08:18 Message: Logged In: YES user_id=21627 Thanks for the report; this was fixed in 43584 and 43585. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463559 ] missing svnversion == configure error
Bugs item #1463559, was opened at 2006-04-03 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: missing svnversion == configure error Initial Comment: Attempting to build the trunk from source on a box without svn installed spits this out of configure: checking for svnversion... no ./configure: line 3616: test: =: unary operator expected We should handle this more gracefully. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 21:12 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in 43604. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&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: Extension Modules Group: Python 2.4 >Status: Open Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) >Assigned to: Georg Brandl (birkenfeld) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: Thomas Heller (theller) Date: 2006-04-03 21:29 Message: Logged In: YES user_id=11105 The patched file does not even compile. I suggest a more careful review, or running the testsuite (on affected system), or even better, a unittest. -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 14:26 Message: Logged In: YES user_id=849994 Rev. 43586. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. -- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=143 Sorry, but I can't work on a patch. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed
Bugs item #1462485, was opened at 2006-04-01 00:17
Message generated for change (Settings changed) made by pje
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Delaney (tcdelaney)
>Assigned to: Phillip J. Eby (pje)
Summary: StopIteration raised in body of 'with' statement suppressed
Initial Comment:
Given:
@contextmanager
def gen():
print '__enter__'
try:
yield
finally:
print '__exit__'
with gen():
raise StopIteration('body')
running the above results in:
__enter__
__exit__
I would have expected instead
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise StopIteration('body')
StopIteration: body
Note that doing:
with gen():
raise GeneratorExit('body')
does the expected thing:
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise GeneratorExit('body')
GeneratorExit: body
--
>Comment By: Phillip J. Eby (pje)
Date: 2006-04-03 20:06
Message:
Logged In: YES
user_id=56214
This looks good, although the second GeneratorExit test
looks redundant. I went ahead and checked it in, however,
on the theory that more tests are better than fewer. :)
--
Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-02 02:42
Message:
Logged In: YES
user_id=603121
Attached diffs to test_with.py which adds tests for raising StopIteration (and
GeneratorExit) from the body of a with-statement where the context manager is
either a generator, or a class instance.
I think the correct behaviour is to return False from
GeneratorContextManager.__exit__ if the thrown exception is a StopIteration,
and the exact same instance is raised from self.gen.throw(). Diffs for this
also attached.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:02
Message:
Logged In: YES
user_id=849994
Nick, I can't tell whether this is intentional without
rereading the specs. Can you?
--
Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-01 00:19
Message:
Logged In: YES
user_id=603121
Attached code and results.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9
Bugs item #1460514, was opened at 2006-03-29 10:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&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: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. -- >Comment By: Thomas Heller (theller) Date: 2006-04-03 22:18 Message: Logged In: YES user_id=11105 As a temporary fix, I removed the '+live_support' attribute in the source file. Andrew, can you please verify that this works for you? Thanks, Thomas -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed
Bugs item #1462485, was opened at 2006-04-01 00:17
Message generated for change (Comment added) made by tcdelaney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Phillip J. Eby (pje)
Summary: StopIteration raised in body of 'with' statement suppressed
Initial Comment:
Given:
@contextmanager
def gen():
print '__enter__'
try:
yield
finally:
print '__exit__'
with gen():
raise StopIteration('body')
running the above results in:
__enter__
__exit__
I would have expected instead
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise StopIteration('body')
StopIteration: body
Note that doing:
with gen():
raise GeneratorExit('body')
does the expected thing:
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise GeneratorExit('body')
GeneratorExit: body
--
>Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-03 20:24
Message:
Logged In: YES
user_id=603121
Realised I had a couple of typos in the comment added to contextlib. Fixed diff
attached.
--
Comment By: Phillip J. Eby (pje)
Date: 2006-04-03 20:06
Message:
Logged In: YES
user_id=56214
This looks good, although the second GeneratorExit test
looks redundant. I went ahead and checked it in, however,
on the theory that more tests are better than fewer. :)
--
Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-02 02:42
Message:
Logged In: YES
user_id=603121
Attached diffs to test_with.py which adds tests for raising StopIteration (and
GeneratorExit) from the body of a with-statement where the context manager is
either a generator, or a class instance.
I think the correct behaviour is to return False from
GeneratorContextManager.__exit__ if the thrown exception is a StopIteration,
and the exact same instance is raised from self.gen.throw(). Diffs for this
also attached.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:02
Message:
Logged In: YES
user_id=849994
Nick, I can't tell whether this is intentional without
rereading the specs. Can you?
--
Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-01 00:19
Message:
Logged In: YES
user_id=603121
Attached code and results.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False
Bugs item #1463840, was opened at 2006-04-03 17:37 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=1463840&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Winkler (slinkp) Assigned to: Nobody/Anonymous (nobody) Summary: logging.StreamHandler ignores argument if it compares False Initial Comment: The docs at http://docs.python.org/lib/node346.html say this: """ class StreamHandler([strm]) Returns a new instance of the StreamHandler class. If strm is specified, the instance will use it for logging output; otherwise, sys.stderr will be used. """ However, that's not quite true. StreamHandler.__init__() actually tests for truth of strm, which means you have to be careful that strm does not happen to evaluate to boolean false. My use case: I'm writing some tests that verify that certain methods put certain strings into the logs. So my setUp() adds a StreamHandler with its stream set to an instance of this trivial class: class FakeLog(list): def write(self, msg): self.append(msg) def flush(self): pass ... which does not work, because an empty list evaluates to false, so my handler writes to stderr even though i told it not to. It's trivial to work around this by adding a __nonzero__ method, but the need to do so is certainly not clear from the docs. Therefore imho this is a bug. The patch is trivial, and is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&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: Extension Modules Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: roee88 (roee88) Assigned to: Georg Brandl (birkenfeld) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-04 01:04 Message: Logged In: YES user_id=21627 For the record: the patch *does* compile (though with warnings), and passes the test suite, see the buildbot log files for details. Nevertheless, there were two serious bugs in the code, which I fixed in 43611. Thanks for pointing that out. -- Comment By: Thomas Heller (theller) Date: 2006-04-03 21:29 Message: Logged In: YES user_id=11105 The patched file does not even compile. I suggest a more careful review, or running the testsuite (on affected system), or even better, a unittest. -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-03 14:26 Message: Logged In: YES user_id=849994 Rev. 43586. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-03 14:21 Message: Logged In: YES user_id=21627 The patch looks fine. Please apply. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-31 17:03 Message: Logged In: YES user_id=849994 Attaching patch. Please check. -- Comment By: roee88 (roee88) Date: 2006-03-22 13:00 Message: Logged In: YES user_id=143 Sorry, but I can't work on a patch. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463926 ] can't build on cygwin - PyArg_Parse_SizeT undefined
Bugs item #1463926, was opened at 2006-04-04 10:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: can't build on cygwin - PyArg_Parse_SizeT undefined Initial Comment: Something's not right on cygwin with the trunk. Example failing build: http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-configure/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-compile/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-test/0 Wrapping the PY_SSIZE_T_CLEAN bit at the top of modsupport.h in an "#if 0"/"#endif" makes it compile, at least. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False
Bugs item #1463840, was opened at 2006-04-03 14:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Winkler (slinkp) >Assigned to: Vinay Sajip (vsajip) Summary: logging.StreamHandler ignores argument if it compares False Initial Comment: The docs at http://docs.python.org/lib/node346.html say this: """ class StreamHandler([strm]) Returns a new instance of the StreamHandler class. If strm is specified, the instance will use it for logging output; otherwise, sys.stderr will be used. """ However, that's not quite true. StreamHandler.__init__() actually tests for truth of strm, which means you have to be careful that strm does not happen to evaluate to boolean false. My use case: I'm writing some tests that verify that certain methods put certain strings into the logs. So my setUp() adds a StreamHandler with its stream set to an instance of this trivial class: class FakeLog(list): def write(self, msg): self.append(msg) def flush(self): pass ... which does not work, because an empty list evaluates to false, so my handler writes to stderr even though i told it not to. It's trivial to work around this by adding a __nonzero__ method, but the need to do so is certainly not clear from the docs. Therefore imho this is a bug. The patch is trivial, and is attached. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 23:20 Message: Logged In: YES user_id=33168 Vinay, any comments? We are preparing for 2.5 alpha1 within a day. There will be freeze real soon now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Bugs item #1463043, was opened at 2006-04-02 07:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Initial Comment:
I built Python-2.4.3 from source on SUSE 9.3 and get
the following error for test_minidom.py
/usr/local/src/Python-2.4.3: ./python
Lib/test/test_minidom.py
Failed Test
Test Failed: testAltNewline
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 427, in
testAltNewline
confirm(domstr == str.replace("\n", "\r\n"))
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed testEncodings - encoding EURO SIGN
Test Failed: testEncodings
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 891, in
testEncodings
"testEncodings - encoding EURO SIGN")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed After replaceChild()
Test Failed: testPatch1094164
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 1137, in
testPatch1094164
confirm(e.parentNode is elem, "After replaceChild()")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed Test
Test Failed: testWriteXML
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 420, in
testWriteXML
confirm(str == domstr)
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Check for failures in these tests:
testAltNewline
testEncodings
testPatch1094164
testWriteXML
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 23:27
Message:
Logged In: YES
user_id=33168
Martin maintains PyXML AFAIK. Maybe he has some ideas. I
suspect this might be even worse in 2.5. Element Tree was
added and there was a name change. Some of those things
still need to be addressed.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-03 06:37
Message:
Logged In: YES
user_id=200117
Hi Neal,
I've just built 2.4.3 on a Red Hat Enterpeise Edition WS
V4.2 machine and this gives the same error.
I've had this vague feeling that I've seen something like
this before, but couldn't find anything when I searched the
tracker...
I've now realised that the error is due to a conflict with
PyXML-0.8.4 which was already installed on both machines.
If I rename the ../site_packages/_xmlplus directory to a
different name then the error goes away (on the Red Hat
machine at least, the SUSE machine is at home).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-02 22:37
Message:
Logged In: YES
user_id=33168
Thanks for letting us know about where the regression
occurred. Can you do a little more debugging to try to find
the cause and some ideas about how to fix it?
I'm not sure that any developer runs on a system that
exhibits this error. So it will probably be very difficult
for us to figure it out since we can't reproduce it.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-02 07:28
Message:
Logged In: YES
user_id=200117
I've just retested with earlier versions.
No error with Python-2.4.1
Similar error with Python-2.4.2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
