Mailman 3 June 2004 - Python-Dev

Re: various test failures - test_site, test_tempfile, test_bsddb/anydbm
by Skip Montanaro 06 Jun '04

06 Jun '04

Regarding this message I'm seeing: *** malloc[24360]: error for object 0x680b408: Pointer being reallocated was not allocated a breakpoint in malloc_printf (handy that) yields this stack trace info near the call: Starting program: /Users/skip/tmp/python/dist/src/python.exe Lib/test/regrtest.py -f ~/tmp/tests test_sundry test_tcl test_tempfile Breakpoint 1, 0x90070ddc in malloc_printf () (gdb) bt 10 #0 0x90070ddc in malloc_printf () #1 0x9000de5c in szone_realloc () #2 0x9000dd70 in malloc_zone_realloc () #3 0x9000dce8 in realloc () #4 0x90010c24 in setenv () #5 0x90010a74 in putenv () #6 0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at Modules/posixmodule.c:5685 #7 0x000d9b84 in PyCFunction_Call (func=0x41c878, arg=0x130e038, kw=0x0) at Objects/methodobject.c:73 #8 0x000ccc1c in call_function (pp_stack=0xbfff9480, oparg=2) at Python/ceval.c:3377 #9 0x000c6dec in eval_frame (f=0xb41738) at Python/ceval.c:1990 (More stack frames follow...) (gdb) f 6 #6 0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at Modules/posixmodule.c:5685 (gdb) p new $2 = 0x1078644 "TMPDIR=/Users/skip/tmp/python/dist/src/TMPDIR" (gdb) pystack /Users/skip/tmp/python/dist/src/Lib/os.py (444): __setitem__ /Users/skip/tmp/python/dist/src/Lib/test/test_tempfile.py (146): test_wanted_dirs /Users/skip/tmp/python/dist/src/Lib/unittest.py (245): run /Users/skip/tmp/python/dist/src/Lib/unittest.py (419): __call__ /Users/skip/tmp/python/dist/src/Lib/unittest.py (419): __call__ /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (249): run /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (255): run_suite /Users/skip/tmp/python/dist/src/Lib/test/test_support.py (278): run_unittest /Users/skip/tmp/python/dist/src/Lib/test/test_tempfile.py (662): test_main Lib/test/regrtest.py (396): runtest Lib/test/regrtest.py (124): main Lib/test/regrtest.py (77): ? It seems that the string posix_putenv() is passing to putenv() is properly allocated. Setting a breakpoint in setenv() I see only three calls to it, two from the readline initialization during test_sundry (it looks like to set LINES and COLS - I have no source for that stuff) and one in test_tempfile to set TMPDIR (the one causing the malloc warning). If I comment out the rlcompleter import in test_sundry the warning disappears and the failing test in test_tempfile succeeds. I'm getting libreadline (version 4.2.0) from fink. I'm not sure what else I can do to debug this problem. Should I bother (readline can be problematic)? Any thoughts? Skip

2 1

python23-maint Branch
by kbk＠shore.net 06 Jun '04

06 Jun '04

Is the branch open for 2.3.5 commit? -- KBK

2 1

RE: [Python-Dev] An ability to specify start and length of slices
by Tim Peters 06 Jun '04

06 Jun '04

[Noam Raphael] > Ok, why not? Long live +: ! So what do people think of the improved, > rational syntax? Perhaps someone who have used Icon can share his/her > experience with us? My recollection was that it was handy more than just a few times, but reviewing some Icon code reminded me of why that was so (see below). In addition to +:, Icon slices also support -:. This relates to another difference in Icon slicing: S[i:j] means the same thing as S[j:i] in Icon. In Python, for fixed S, i and j, at least one of those forms is an empty slice. In the Icon program library distributed with Icon 9.4, there are about 200K lines of Icon source in about 1200 files. 139 lines match the regexp [-+]\s*:(?!=) (since Icon uses := for assignment, the negative lookahead on "=" is needed to weed out the Icon augmented assignments +:=, -:=, ++:= and --:=) So it's not used a lot by Icon experts (< 1 per 1000 lines). What staring at this reminded me of (and which I had forgotten) is that the most *common* use of +: in Icon is slices of the form S[1+:n] to get the leftmost n elements. Python spells this S[:n] but specifying a starting index isn't optional in Icon. The handful of uses of -: outside the test suite are all of the form S[0:-n] which Python spells S[-n:] (get the rightmost n elements). Several dozen "non-trivial" uses of +: remain, but it's hard to get excited about them; e.g., line[x+:2] := "[" is marginally easier than line[x:x+2] := "[" but Python doesn't support assigning to string slices anyway. "abcde"[2+:2] was an elaborate way to spell "bc" This is a good use: every push(layout,show(deck[(0 to 3) * handsize + 1 +: handsize])) The closest Python is layout = [show(deck[i*handsize:(i+1)*handsize]) for i in range(4)] and layout = [show(deck[i*handsize +: handsize]) for i in range(4)] would indeed be clearer. That's not enough (IMO) to be worth the pain of changing the language, though. Note that if you have a lot of fixed-field strings to parse, the struct module already supplies a nice way to spell that; e.g., to pick apart 8-character HH:MM:SS strings, >>> def hms(s): ... import struct ... return struct.unpack('2sx2sx2s', s) ... >>> hms('01:12:45') ('01', '12', '45') >>> That's better (clearer, easier, faster) than coding a bunch of fiddly indexing too.

1 0

Re: [Python-Dev] Free Icon books
by kbk＠shore.net 06 Jun '04

06 Jun '04

"Tim Peters" <tim.one(a)comcast.net> writes: > I especially recommend the "Design & Implementation" book, which is > out of print. There are few good books about the implementations of > very high level languages, and this book is excellent. It no longer > matches the current implementation of Icon in several respects, but > who cares <wink>. Cool, thanks. Ah, the good old days: "Since the initial work was done on a PDP-11/70, with a user address space of only 128K bytes (combined instruction and data spaces), the size of the implementation was of significant concern." -- KBK

1 0

Free Icon books
by Tim Peters 06 Jun '04

06 Jun '04

Speaking of Icon, the 3 major books published on it are available for free downloading in PDF format now: http://www.cs.arizona.edu/icon/books.htm I especially recommend the "Design & Implementation" book, which is out of print. There are few good books about the implementations of very high level languages, and this book is excellent. It no longer matches the current implementation of Icon in several respects, but who cares <wink>. Two (also free) separate technical reports try to explain how the current implementation differs: http://www.cs.arizona.edu/icon/docs/ipd112.htm http://www.cs.arizona.edu/icon/docs/ipd239.htm

1 0

Re: [Python-Dev] Allowing uploads in bug tracker
by Troels Walsted Hansen 05 Jun '04

05 Jun '04

Tim Peters wrote: >For the duration, people who want to attach files will need to get a Python >developer to attach them (all Python developers I added to the project have >the "Tech & Admin" role on all Python trackers; developers added by other >project admins may not; if you're a Python developer and cannot attach a >file to a tracker item, let me know and I'll boost your permissions). > > I ran into this problem with bug item <http://python.org/sf/777597> My solution was to create a new patch item <http://python.org/sf/965036> and reference the bug item in the comments. Of course, my solution would have been less appropriate if the file I needed to attach had been something other than a patch... Troels

1 0

Re: [Python-Dev] Dropping decorator syntax for 2.4?
by Michel Pelletier 05 Jun '04

05 Jun '04

> > I agree with Brett that Guido is usually right, so I'm curious about his > > decision. > > I plan to talk it through with people at EuroPython next week. > > --Guido van Rossum (home page: http://www.python.org/~guido/) I know there's a 2.4 crunch, but if the decision is put off a month longer, you can also get face time with a lot of people at OSCON and Vanpyz on this issue. Sorry about the delay, I get digests. -Michel

1 0

An ability to specify start and length of slices
by Noam Raphael 05 Jun '04

05 Jun '04

Hello, Many times I find myself asking for a slice of a specific length, rather than a slice with a specific end. I suggest to add the syntax object[start:>length] (or object[start:>length:jump]), beside the existing syntax. Two examples: 1. Say I have a list with the number of panda bears hunted in each month, starting from 1900. Now I want to know how many panda bears were hunted in year y. Currently, I have to write something like this: sum(huntedPandas[(y-1900)*12:(y-1900)*12+12]) If my suggestion is accepted, I would be able to write: sum(huntedPandas[(y-1900)*12:>12]) 2. Many data files contain fields of fixed length. Just an example: say I want to get the color of the first pixel of a 24-bit color BMP file. Say I have a function which gets a 4-byte string and converts it into a 32-bit integer. The four bytes, from byte no. 10, are the size of the header, in bytes. Right now, if I don't want to use temporary variables, I have to write: picture[s2i(picture[10:14]):s2i(picture[10:14])+4] I think this is nicer (and quicker): picture[s2i(picture[10:>4]):>4] (I mean to show that when working with data files, it's common to have slices of specific length, and that the proposed syntax makes things clear and simple. I took BMP just as an example - I know about PIL.) Other solutions (from comp.lang.python responses): 1. Of course, the longer form may be used, and a temporary variable may be used to avoid repeated function calls. 2. The idiom object[start:][:length] may be used. However, it may be very inefficient, if the list is long. Another advantage of the proposed syntax is that it can be used in multi-dimensional slices (for example, ar[:,x:>3,:]) 3. The programmer may define the function lambda object, start, length: object[start:start+length]. This does make expressions quite short, but it isn't very readable IMHO, and doesn't deal with multi-dimensional slices. Objections (also from comp.lang.python): 1. There should be only one way to do something in Python. 2. Some don't like how it looks. 3. l[a:b] yields an empty list when a>b, and l[a:>b] doesn't. My responses: 1. Changes should be taken seriously, and the language must be kept simple and easy to read, but it doesn't mean that there should be only one way to do something. Just an example: you could write l[:,:,:,3], but the ellipsis token lets you write l[...,3]. 2. I can't really argue with that, besides saying that it looks fine to me; The symbol '>' generally means "move to the right". I think that l[12345:>10] can easily be read as "start from 12345, and move 10 steps to the right. Take all the items you passed over." 3. l[a:>b] doesn't look like l[a:b] and it means something altogether different. Besides, l[a:b:-1] doesn't yield an empty list when a > b. Some technical details: My proposal only affects the conversion from Python code into byte-code. This is why it is easy to implement and has no side effects, as far as I can see. I changed the definition of "subscript" in the Grammar file from: subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop] into: subscript: '.' '.' '.' | test | ([test] ':' [test] | test ':>' test) [sliceop] and added the ':>' token to tokenize.c and token.h. I then extended compile.c to handle the new syntax. The byte code produced is basically simple: Calculate start, calculate length, and add start to length to get the usual start, end. It gets a bit complicated because you want range(10)[3:>-5], for example, to yield an empty list, and using the method described, it will be equivalent to range(10)[3:-2], that is, to [3,4,5,6,7]. So the byte-code my implementation produces checks to see if the resulting end is negative and start is positive, and if so, puts -sys.maxint, instead of start+length, as end. -sys.maxint is used instead of the more obvious choice, 0, so that range(10)[3:>-5:-1] will yield [3,2,1,0] and not [3,2,1]. This can be optimized, because I expect that usually length will be an integer given explicitly in the Python code, in which case no testing has to be done in the byte-code. Attached are the 4 diffs. I'm sorry, they are against the Python-2.3.3 release (the sourceforge CVS doesn't work for me currently), but I expect them to work fine with the CVS head. To summerize, this is a small addition, with no side-effects or backward-compatibility issues, which will help me and others. Well, what do you think? I would like to hear your comments. Best wishes, Noam Raphael

7 7

Weekly Python Bug/Patch Summary
by Kurt B. Kaiser 05 Jun '04

05 Jun '04

Patch / Bug Summary ___________________ Patches : 274 open ( -6) / 2401 closed (+10) / 2675 total ( +4) Bugs : 762 open (-13) / 4094 closed (+36) / 4856 total (+23) RFE : 138 open ( +1) / 128 closed ( +1) / 266 total ( +2) New / Reopened Patches ______________________ Fix for #777597 - socketmodule.c connection handling incorec (2004-06-02) http://python.org/sf/965036 opened by Troels Walsted Hansen improve markupbase.py error reporting (2004-06-02) http://python.org/sf/965175 opened by No Spam improve markupbase.py error reporting (2004-06-02) CLOSED http://python.org/sf/965192 opened by No Spam Cleanup generator/eval_frame exposure (2004-06-04) http://python.org/sf/966493 opened by James William Pye Patches Closed ______________ Improved hash for tuples (2004-05-19) http://python.org/sf/957122 closed by rhettinger East Asian Width support for Unicode (2004-05-29) http://python.org/sf/962502 closed by perky Public Generator Object/Type (2004-05-20) http://python.org/sf/957398 closed by loewis Fix os.stat handling of UNC roots (2004-05-14) http://python.org/sf/954115 closed by loewis Use .dylib for shared objects on MacOS X (2002-11-21) http://python.org/sf/641685 closed by jackjansen Patch for feature request 491033 (2004-05-20) http://python.org/sf/957240 closed by loewis Improvements to Bluetooth support (2004-04-04) http://python.org/sf/929192 closed by loewis improve markupbase.py error reporting (2004-06-02) http://python.org/sf/965192 closed by nnorwitz Make IDLE's paragraph reformatting width configurable (2004-05-27) http://python.org/sf/961387 closed by rhettinger Patch to setup.py to run on x86_64 Linux (2004-03-30) http://python.org/sf/926209 closed by loewis New / Reopened Bugs ___________________ random.choice([]) should return more intelligible exception (2004-06-01) http://python.org/sf/964230 opened by Michael Hoffman Cannot encode 5 digit unicode. (2004-06-01) CLOSED http://python.org/sf/964284 opened by Bugs Fly email package uses \n to rebuild content of a message (2004-06-01) http://python.org/sf/964433 opened by Marco Bizzarri idle help is modal (2004-06-01) http://python.org/sf/964437 opened by Matthias Klose Boolean operations section includes lambda_form grammar rule (2004-06-01) CLOSED http://python.org/sf/964525 opened by Stefanus Du Toit 2.3.4 Language Reference Typo, Section 2.3.2 (2004-06-02) CLOSED http://python.org/sf/964592 opened by Chris Wood RFE versus Bug group Feature Request (2004-06-01) CLOSED http://python.org/sf/964703 opened by Terry J. Reedy Cookie module does not parse date (2004-06-02) http://python.org/sf/964861 opened by Manlio Perillo pickle protocol 2 is incompatible(?) with Cookie module (2004-06-02) http://python.org/sf/964868 opened by Manlio Perillo sys.getfilesystemencoding() (2004-06-02) http://python.org/sf/964870 opened by Manlio Perillo mapping a 0 length file (2004-06-02) http://python.org/sf/964876 opened by Manlio Perillo Unicode String formatting does not correctly handle objects (2004-06-02) http://python.org/sf/964929 opened by Giles Antonio Radford Ctrl-C causes odd behaviour (2004-06-02) http://python.org/sf/964949 opened by Michael Bax datetime.isoformat() contaiins 'T0' (2004-06-02) CLOSED http://python.org/sf/965032 opened by Doug Fort document docs.python.org in PEP-101 (2004-06-03) http://python.org/sf/965065 opened by Anthony Baxter importing dynamic modules via embedded python (2004-06-02) http://python.org/sf/965206 opened by Anne Wilson textwrap does not handle single quotes with hyphens properly (2004-06-02) CLOSED http://python.org/sf/965425 opened by Greg Ward isinstance fails to recognize instance (2004-06-03) CLOSED http://python.org/sf/965562 opened by Ib Jørgensen Build Python 2.3.3 or 4 on RedHat Enterprise fails (2004-06-03) CLOSED http://python.org/sf/965991 opened by Russell Owen realpath description misleading (2004-06-04) http://python.org/sf/966256 opened by GaryD Typo in whatsnew24/genexprs (2004-06-04) CLOSED http://python.org/sf/966375 opened by Kristian Ovaska Typo in whatsnew24/genexprs (2004-06-04) CLOSED http://python.org/sf/966387 opened by Kristian Ovaska import x.y inside of module x.y (2004-06-04) http://python.org/sf/966431 opened by Armin Rigo float_subtype_new() bug (2004-06-04) http://python.org/sf/966618 opened by Armin Rigo execfile, type, __module__, who knows ;) (2004-06-05) http://python.org/sf/966623 opened by Anthony Baxter Documentation for Descriptors in the main docs (2004-06-05) http://python.org/sf/966625 opened by Raide LaTeX not required (2004-05-05) http://python.org/sf/948517 reopened by aahz Bugs Closed ___________ Weakness in tuple hash (2004-04-27) http://python.org/sf/942952 closed by rhettinger Distutils should be able to produce Debian packages (.deb) (2004-05-31) http://python.org/sf/963825 closed by akuchling Typo in Lib/test/test_sax.py can confuse (2004-05-29) http://python.org/sf/962631 closed by akuchling Cannot encode 5 digit unicode. (2004-06-01) http://python.org/sf/964284 closed by mozbugbox Boolean operations section includes lambda_form grammar rule (2004-06-01) http://python.org/sf/964525 closed by loewis 2.3.4 Language Reference Typo, Section 2.3.2 (2004-06-01) http://python.org/sf/964592 closed by loewis RFE versus Bug group Feature Request (2004-06-01) http://python.org/sf/964703 closed by tim_one isdir behavior getting odder on UNC path (2002-02-06) http://python.org/sf/513572 closed by loewis socket timeouts produce wrong errors in win32 (2003-03-24) http://python.org/sf/708927 closed by glchapman IPV6 not correctly ifdef'd in socketmodule.c (2004-03-27) http://python.org/sf/924294 closed by loewis PyModule_AddIntConstant documented to take an int, not a lon (2004-05-28) http://python.org/sf/962471 closed by loewis grammar for "class" inheritance production slightly wrong (2004-05-26) http://python.org/sf/960448 closed by loewis datetime.isoformat() contaiins 'T0' (2004-06-02) http://python.org/sf/965032 closed by anthonybaxter Incorrect __name__ assignment (2004-03-26) http://python.org/sf/923576 closed by jackjansen textwrap does not handle single quotes with hyphens properly (2004-06-02) http://python.org/sf/965425 closed by gward isinstance fails to recognize instance (2004-06-03) http://python.org/sf/965562 closed by doerwalter locale dependency of string methods undocumented (2004-04-15) http://python.org/sf/935749 closed by loewis type of Py_UNICODE depends on ./configure options (2004-01-22) http://python.org/sf/881861 closed by loewis Python 2.4: Warn about omitted mutable_flag. (2003-03-03) http://python.org/sf/696535 closed by loewis pimp needs to do download itself (2003-04-10) http://python.org/sf/719300 closed by jackjansen MacOS9: installer should test CarbonLib version (2003-08-04) http://python.org/sf/783095 closed by jackjansen PythonIDE crashes on very large scripts folder (2004-05-24) http://python.org/sf/959291 closed by jackjansen AskFolder (EasyDialogs) does not work? (2004-03-09) http://python.org/sf/912758 closed by jackjansen -fconstant-cfstrings required for Xcode 1.2 (2004-05-08) http://python.org/sf/950482 closed by jackjansen Unable to overwrite file with findertools.move (2004-03-09) http://python.org/sf/912747 closed by jackjansen PythonLauncher-run scripts have funny $CWD (2004-03-10) http://python.org/sf/913581 closed by jackjansen #!/usr/bin/python can find wrong python (2004-04-10) http://python.org/sf/932977 closed by jackjansen Python 2.3.3 won't build on MacOSX 10.2 (2003-12-23) http://python.org/sf/864985 closed by jackjansen InfoPlist.strings files are UTF-16. (2003-07-04) http://python.org/sf/765888 closed by jackjansen bundlebuilder standalone app doesn't fully quit (2004-02-02) http://python.org/sf/889200 closed by jackjansen I would like an easy way to get to file creation date (2004-01-16) http://python.org/sf/878581 closed by jackjansen PythonIDE on osx can't run script with commandline python (2003-12-19) http://python.org/sf/862941 closed by jackjansen PythonIDE does not save for PythonLauncher (2003-12-15) http://python.org/sf/860242 closed by jackjansen Typo in whatsnew24/genexprs (2004-06-04) http://python.org/sf/966375 closed by perky Typo in whatsnew24/genexprs (2004-06-04) http://python.org/sf/966387 closed by perky C/C++ extensions w/ Python + Mingw (Windows) (2004-05-20) http://python.org/sf/957198 closed by theller Build Python 2.3.3 or 4 on RedHat Enterprise fails (2004-06-04) http://python.org/sf/965991 closed by anthonybaxter Bad error mesage when subclassing a module (2004-05-31) http://python.org/sf/963956 closed by rhettinger RFE Closed __________ asyncore - api doesn't provide doneevent (2001-12-10) http://python.org/sf/491033 closed by loewis

1 0

'Buggy' feature requests
by Terry Reedy 04 Jun '04

04 Jun '04

Some items in the bug list are feature requests that better belong in the RFE list, in spite of the unremovable Bugs list Feature Request group. Seeking more authoritative guidance than my own feelings, and hoping to get something I could direct feature-missing-is-a-bug posters to, I opened item 964703. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964703&group_i… In responding (and closing) Tim Peters nicely fulfilled both goals. Perhaps other bug reviewers might find this item a handy reference when trying to prune the bug list, and perhaps closing requests as not-a-bug. Terry J. Reedy

1 0