Mailman 3 February 2001 - Python-Dev

Set and Iterator BOFs
by Greg Wilson 12 Feb '01

12 Feb '01

Barbara Fuller at Foretec has set up two mailing lists: Iterator-BOF(a)python9.org (for March 6) Set-BOF(a)python9.org (for March 7) for discussing admin related to these BOFs. If you are planning to attend, please send mail to the list, so that she can plan room allocation, make sure we get seated first for lunch, etc. Greg

2 1

Fatal scoping error from the twilight zone
by Ka-Ping Yee 12 Feb '01

12 Feb '01

Houston, we may have a problem... The following harmless-looking function: def getpager(): """Decide what method to use for paging through text.""" if type(sys.stdout) is not types.FileType: return plainpager if not sys.stdin.isatty() or not sys.stdout.isatty(): return plainpager if os.environ.has_key('PAGER'): return lambda text: pipepager(text, os.environ['PAGER']) if sys.platform in ['win', 'win32', 'nt']: return lambda text: tempfilepager(text, 'more') if hasattr(os, 'system') and os.system('less 2>/dev/null') == 0: return lambda text: pipepager(text, 'less') import tempfile filename = tempfile.mktemp() open(filename, 'w').close() try: if hasattr(os, 'system') and os.system('more %s' % filename) == 0: return lambda text: pipepager(text, 'more') else: return ttypager finally: os.unlink(filename) produces localhost[1047]% ./python ~/dev/htmldoc/pydoc.py Fatal Python error: unknown scope for pipepager in getpager(5) in /home/ping/dev/htmldoc/pydoc.py Aborted (core dumped) localhost[1048]% with a clean build on a CVS tree that i updated just minutes ago. I was able to reduce this test case to the following: localhost[1011]% python Python 2.1a2 (#20, Feb 3 2001, 20:40:19) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> def getpager(): ... if os.environ.has_key('x'): ... return lambda t: pipepager(t, os.environ['x']) ... Fatal Python error: unknown scope for pipepager in getpager (1) Aborted (core dumped) but not before coming across a bewildering series of working and non-working cases that left me wondering whether i was hallucinating. Strange as it may seem, for example, replacing the string constant 'x' with a variable makes the latter example work. Even stranger, choosing a different name for the variable t can make it work in some cases but not others! Please try the following script and see if you get weird results: code = '''def getpager(): if os.environ.has_key('x'): return lambda %s: pipepager(%s, os.environ['x'])''' import string, os, sys results = {} for char in string.letters: f = open('/tmp/test.py', 'w') f.write(code % (char, char) + '\n') f.close() sys.stderr.write('%s: ' % char) status = os.system('python /tmp/test.py > /dev/null') >> 8 sys.stderr.write('%s\n' % status) results.setdefault(status, []).append(char) for status in results.keys(): if not status: print 'Python likes these letters:', else: print 'Status %d for these letters:' % status, print results[status] I get this, consistently every time! Status 134 for these letters: ['b', 'c', 'd', 'g', 'h', 'j', 'k', 'l', 'o', 'p', 'r', 's', 't', 'w', 'x', 'z', 'B', 'C', 'D', 'G', 'H', 'J', 'K', 'L', 'O', 'P', 'R', 'S', 'T', 'W', 'X', 'Z'] Python likes these letters: ['a', 'e', 'f', 'i', 'm', 'n', 'q', 'u', 'v', 'y', 'A', 'E', 'F', 'I', 'M', 'N', 'Q', 'U', 'V', 'Y'] A complete log of my interactive sessions is attached. I hope somebody can reproduce at least some of this to assure me that i'm not going mad. :) -- ?!ng Happiness comes more from loving than being loved; and often when our affection seems wounded it is is only our vanity bleeding. To love, and to be hurt often, and to love again--this is the brave and happy life. -- J. E. Buchrose

3 3

Removing the implicit str() call from printing API
by M.-A. Lemburg 12 Feb '01

12 Feb '01

There was some discussion about this subject before, but nothing much happened, so here we go again... Printing in Python is a rather complicated task. It involves many different APIs, flags, etc. Deep down in the printing machinery there is a hidden call to str() which converts the to be printed object into a string object. This is fine for non-string objects like numbers, but causes trouble when it comes to printing Unicode objects due to the auto-conversions this causes. There is a patch on SF which tries to remedy this, but it introduces a special attribute to maintain backward compatibility: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 I don't really like the idea to add such an attribute to the file object. Instead, I think that we should simply pass along Unicode objects as-is to the file object's .write() method and have the method take care of the conversion. This will break some code, since not all file-like objects expect non-strings as input to the .write() method, but I think this small code breakage is worth it as it allows us to redirect printing to streams which convert Unicode input into a specific output encoding. Thoughts ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 7

Re: [Python-checkins] CVS: python/dist/src Makefile.pre.in,1.14,1.15
by Thomas Wouters 11 Feb '01

11 Feb '01

On Fri, Feb 09, 2001 at 02:22:20PM -0800, Jeremy Hylton wrote: > Log Message: > Relax the rules for using 'from ... import *' and exec in the presence > of nested functions. Either is allowed in a function if it contains > no defs or lambdas or the defs and lambdas it contains have no free > variables. If a function is itself nested and has free variables, > either is illegal. Wow. Thank you, Jeremy, I'm very happy with that! It's even better than I dared hope for, since it means *most* lambdas (the simple ones that don't reference globals) won't break functions using 'from .. import *', and the ones that do reference globals can be fixed by doing 'global_var=global_var' in the lambda argument list ( -- maybe we should put that in the docs ?) +1-on-suffering-fools-a-whole-release-before-punishing-them-for-it-ly y'rs, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

dl module
by Andrew Kuchling 11 Feb '01

11 Feb '01

The dl module isn't automatically compiled by setup.py, and at least one patch on SourceForge adds it. Question: should it be compiled as a standard module? Using it can, according to the comments, cause core dumps if you're not careful. Question: does anyone actually use the dl module? If not, maybe it could be dropped. --amk

6 5

Re: [Python-Dev] test_inspect fails again: segfault in compile
by Michael Hudson 11 Feb '01

11 Feb '01

Ka-Ping Yee <ping(a)lfw.org> writes: > After further testing, it seems to come down to this: > > Python 2.1a2 (#22, Feb 10 2001, 16:15:14) > [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> def spam(a, b): pass > ... > >>> def spam(a=3, b): pass > ... > SyntaxError: non-default argument follows default argument > >>> def spam(a=3, b=4): pass > ... > >>> def spam(a, (b,)): pass > ... > >>> def spam(a=3, (b,)): pass > ... > Segmentation fault (core dumped) > > Python 2.1a2 (#22, Feb 10 2001, 16:15:14) > [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> def spam(a=3, (b,)=(4,)): pass > ... > Segmentation fault (core dumped) > Try this: Index: compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.162 diff -c -r2.162 compile.c *** compile.c 2001/02/09 22:55:26 2.162 --- compile.c 2001/02/11 16:19:02 *************** *** 4629,4635 **** for (j = 0; j <= complex; j++) { c = CHILD(n, j); if (TYPE(c) == COMMA) ! c = CHILD(n, ++j); if (TYPE(CHILD(c, 0)) == LPAR) symtable_params_fplist(st, CHILD(c, 1)); } --- 4629,4637 ---- for (j = 0; j <= complex; j++) { c = CHILD(n, j); if (TYPE(c) == COMMA) ! c = CHILD(n, ++j); ! else if (TYPE(c) == EQUAL) ! c = CHILD(n, j += 3); if (TYPE(CHILD(c, 0)) == LPAR) symtable_params_fplist(st, CHILD(c, 1)); } Clearly there should be a test for this - where? test_extcall isn't really appropriate, but I can't think of a better place. Maybe it should be renamed to test_funcall.py and then a test for this can go in. Cheers, M. -- Some people say that a monkey would bang out the complete works of Shakespeare on a typewriter give an unlimited amount of time. In the meantime, what they would probably produce is a valid sendmail configuration file. -- Nicholas Petreley

1 0

Removing the implicit str() call from printing API
by Andy Robinson 11 Feb '01

11 Feb '01

> So far, noone has commented on this idea. > > I would like to go ahead and check in patch which passes through > Unicode objects to the file-object's .write() method while leaving > the standard str() call for all other objects in place. > I'm behind this in principle. Here's an example of why: >>> tokyo_utf8 = "??" # the kanji for Tokyo, trust me... >>> print tokyo_utf8 # this is 8-bit and prints fine æ±äº¬ >>> tokyo_uni = codecs.utf_8_decode(tokyo_utf8)[0] >>> print tokyo_uni # try to print the kanji Traceback (innermost last): File "<interactive input>", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) >>> Let's say I am generating HTML pages and working with Unicode strings containing data > 127. It is far more natural to write a lot of print statements than to have to (a) concatenate all my strings or (b) do this on every line that prints something: print tokyo_utf8.encode(my_encoding) We could trivially make a file object which knows to convert the output to, say, Shift-JIS, or even redirect sys.stdout to such an object. Then we could just print Unicode strings to it. Effectively, the decision on whether a string is printable is deferred to the printing device. I think this is a good pattern which encourages people to work in Unicode. I know nothing of the Python internals and cannot help weigh up how serious the breakage is, but it would be a logical feature to add. - Andy Robinson

2 2

import succeeds on second try?
by Ka-Ping Yee 10 Feb '01

10 Feb '01

This is weird: localhost[1118]% ll spam* -rw-r--r-- 1 ping users 69 Feb 10 17:40 spam.py localhost[1119]% ll eggs* /bin/ls: eggs*: No such file or directory localhost[1120]% cat spam.py a = 1 print 'hello' import eggs # no such file print 'goodbye' b = 2 localhost[1121]% python Python 2.1a2 (#22, Feb 10 2001, 16:15:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import spam hello Traceback (most recent call last): File "<stdin>", line 1, in ? File "spam.py", line 3, in ? import eggs # no such file ImportError: No module named eggs >>> import spam >>> dir(spam) ['__builtins__', '__doc__', '__file__', '__name__', 'a'] >>> localhost[1122]% ll spam* -rw-r--r-- 1 ping users 69 Feb 10 17:40 spam.py -rw-r--r-- 1 ping users 208 Feb 10 17:41 spam.pyc localhost[1123]% ll eggs* /bin/ls: eggs*: No such file or directory Why did Python write spam.pyc after the import failed? -- ?!ng Happiness comes more from loving than being loved; and often when our affection seems wounded it is is only our vanity bleeding. To love, and to be hurt often, and to love again--this is the brave and happy life. -- J. E. Buchrose

2 3

test_inspect fails again: segfault in compile
by Ka-Ping Yee 10 Feb '01

10 Feb '01

Sorry to be the bearer of so much bad news today. When i run the tests for inspect.py, a recently-built Python crashes: localhost[1168]% !p python test_inspect.py Segmentation fault (core dumped) gdb says: (gdb) where #0 0x806021c in symtable_params (st=0x80e9678, n=0x8149340) at Python/compile.c:4633 #1 0x806004f in symtable_funcdef (st=0x80e9678, n=0x8111368) at Python/compile.c:4541 #2 0x805fc6e in symtable_node (st=0x80e9678, n=0x80eaac0) at Python/compile.c:4417 #3 0x8060007 in symtable_node (st=0x80e9678, n=0x811c1c0) at Python/compile.c:4528 #4 0x805f23e in symtable_build (c=0xbffff2a4, n=0x811c1c0) at Python/compile.c:3974 #5 0x805ee8a in jcompile (n=0x811c1c0, filename=0x81268e4 "@test", base=0x0) at Python/compile.c:3853 #6 0x805ed7c in PyNode_Compile (n=0x811c1c0, filename=0x81268e4 "@test") at Python/compile.c:3806 #7 0x8063476 in parse_source_module (pathname=0x81268e4 "@test", fp=0x81271c0) at Python/import.c:611 #8 0x8063637 in load_source_module (name=0x812a1dc "testmod", pathname=0x81268e4 "@test", fp=0x81271c0) at Python/import.c:731 #9 0x8065161 in imp_load_source (self=0x0, args=0x80e838c) at Python/import.c:2178 #10 0x8058655 in call_cfunction (func=0x8124a08, arg=0x80e838c, kw=0x0) at Python/ceval.c:2749 #11 0x8058550 in call_object (func=0x8124a08, arg=0x80e838c, kw=0x0) at Python/ceval.c:2703 #12 0x8058c61 in do_call (func=0x8124a08, pp_stack=0xbffff908, na=2, nk=0) at Python/ceval.c:3014 #13 0x8057228 in eval_code2 (co=0x815eff0, globals=0x80c3544, locals=0x80c3544, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1895 #14 0x8054787 in PyEval_EvalCode (co=0x815eff0, globals=0x80c3544, locals=0x80c3544) at Python/ceval.c:336 #15 0x8068f44 in run_node (n=0x8106f30, filename=0xbffffbb4 "test_inspect.py", globals=0x80c3544, locals=0x80c3544) at Python/pythonrun.c:920 #16 0x8068f09 in run_err_node (n=0x8106f30, filename=0xbffffbb4 "test_inspect.py", globals=0x80c3544, locals=0x80c3544) at Python/pythonrun.c:908 #17 0x8068ee7 in PyRun_FileEx (fp=0x80bf6a8, filename=0xbffffbb4 "test_inspect.py", start=257, globals=0x80c3544, locals=0x80c3544, closeit=1) at Python/pythonrun.c:900 #18 0x80686bc in PyRun_SimpleFileEx (fp=0x80bf6a8, filename=0xbffffbb4 "test_inspect.py", closeit=1) at Python/pythonrun.c:613 #19 0x8068310 in PyRun_AnyFileEx (fp=0x80bf6a8, filename=0xbffffbb4 "test_inspect.py", closeit=1) at Python/pythonrun.c:467 #20 0x8051bb0 in Py_Main (argc=1, argv=0xbffffa84) at Modules/main.c:292 #21 0x80516d6 in main (argc=2, argv=0xbffffa84) at Modules/python.c:10 #22 0x40064cb3 in __libc_start_main (main=0x80516c8 <main>, argc=2, argv=0xbffffa84, init=0x8050bd8 <_init>, fini=0x80968dc <_fini>, rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffa7c) at ../sysdeps/generic/libc-start.c:78 The contents of test_inspect.py and of @test (the Python module which test_inspect writes out and imports) are attached. n_lineno is 8, which points to the hairy line: def spam(a, b, c, d=3, (e, (f,))=(4, (5,)), *g, **h): The following smaller test case reproduces the error: Python 2.1a2 (#22, Feb 10 2001, 16:15:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> def spam(a, b, c, d=3, (e, (f,))=(4, (5,)), *g, **h): ... pass ... Segmentation fault (core dumped) After further testing, it seems to come down to this: Python 2.1a2 (#22, Feb 10 2001, 16:15:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> def spam(a, b): pass ... >>> def spam(a=3, b): pass ... SyntaxError: non-default argument follows default argument >>> def spam(a=3, b=4): pass ... >>> def spam(a, (b,)): pass ... >>> def spam(a=3, (b,)): pass ... Segmentation fault (core dumped) Python 2.1a2 (#22, Feb 10 2001, 16:15:14) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> def spam(a=3, (b,)=(4,)): pass ... Segmentation fault (core dumped) -- ?!ng Happiness comes more from loving than being loved; and often when our affection seems wounded it is is only our vanity bleeding. To love, and to be hurt often, and to love again--this is the brave and happy life. -- J. E. Buchrose

1 0

Re: [Python-Dev] Status of Python in the Red Hat 7.1 beta
by Michael Hudson 10 Feb '01

10 Feb '01

Neil Schemenauer <nas(a)python.ca> writes: > On Fri, Feb 09, 2001 at 10:53:53AM -0500, Michael Tiemann wrote: > > OTOH, if somebody can make a really definitive statement that I've > > misinterpreted the responses, and that 2.x _as_ python should just work, > > and if it doesn't, it's a bug that needs to shake out, I can address that > > with our OS team. > > I'm not sure what you mean by "should just work". Source > compatibility between 1.5.2 and 2.0 is very high. The 2.0 NEWS > file should list all the changes (single argument append and > socket addresses are the big ones). The two versions are _not_ > binary compatible. Python bytecode and extension modules have to > be recompiled. I don't know if this is a problem for the Red Hat > 7.1 release. Another issue is that there is an increasing body of code out there that doesn't work with 1.5.2. Practically all the code I write uses string methods and/or augmented assignment, for example, and I occasionally get email saying "I tried to run your code and got this AttributeEror: join error message". Also there have been some small changes at the C API level around memory management, and I'd much rather program to Python 2.0 here because its APIs are *better*. The world will be a better place when everybody runs Python 2.x, and distributions make a lot of difference here. Just my £0.02. Cheers, M. -- To summarise the summary of the summary:- people are a problem. -- The Hitch-Hikers Guide to the Galaxy, Episode 12

1 0