Mailman 3 March 2005 - Python-Dev

[AST] A somewhat less trivial patch than the last one. . .
by Nick Coghlan 22 Mar '05

22 Mar '05

I've put a first cut at generator expressions for the AST branch on Sourceforge. It's enough to get test_grammar to pass, and tinkering at the interactive prompt appears to work. The patch also fixes a problem with displaying interim results for functions entered at the interactive prompt (I noticed it when trying to get the AST branch genexp bytecode to roughly match that produced by Python 2.4). I didn't check if classes suffer from the same problem, though. Finally, the patch fixes asdl_seq_new to avoid allocating large chunks of memory when passed a size of zero. (This one bit me when trying to get generator expressions to work as arguments - a function call may end up with zero length asdl sequences for either the positional or the keyword arguments). Patch number is 1167628. Cheers, Nick. P.S. Could the powers-that-be add me to the developer list on Sourceforge? I'm interested in better access to the SF trackers, rather than CVS access, though. -- Nick Coghlan | ncoghlan(a)email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

1 1

Draft PEP to make file objects support non-blocking mode.
by Donovan Baarda 22 Mar '05

22 Mar '05

G'day, the recent thread about thread semantics for file objects reminded me I had a draft pep for extending file objects to support non-blocking mode. This is handy for handling files in async applications (the non-threaded way of doing things concurrently). Its pretty rough, but if I fuss over it any more I'll never get it out... -- Donovan Baarda <abo(a)minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/

7 16

[AST] question about marshal_write_*() fxns
by Brett C. 22 Mar '05

22 Mar '05

For those of you who don't know, I am sprinting on the AST branch here on PyCon. Specifically, I am fleshing out Python/compile.txt so that it can act as a good intro to new users and as a design doc. But one of things I am not sure of is what the marshal_write_*() functions in Python/Python-ast.c are used for. I assume they output to the marshal format, but there is mention of a byte stream format and so I thought it might be that as well. Anyone know which one it is? -Brett

3 3

Patch review: all webbrowser.py related patches up to 2005-03-20
by rodsenra＠gpr.com.br 22 Mar '05

22 Mar '05

1144816 webbrowser.Netscape.open bug fix ----------------------------------------------------------------- 1077979 Simple webbrowser fix for netscape -remote ----------------------------------------------------------------- 1144816 and 1077979 are the the same patch, as documented in a comment for 1144816 by Oleg Broytmann. The wrong behaviour was reported to happen in Mozilla (unspecified version), Netscape 7.2 and Mozilla-firefox (unspecified version). I could not reproduce the problem neither with Mozilla 1.7.2 nor with Firefox 1.0.1. Nevertheless, applying the patch does not break current functionality and might fix bugs in older browsers. I recommend applying 1077979, and closing 1144816. 954628 Replacement for webbrowser.py which has problems. ----------------------------------------------------------------- There is no patch attached, but the whole file was uploaded. Twice! There is already a comment by Oleg Broytmann telling the person to re-submit it in as a proper patch. There are multiple changes in it, perhaps multiples patches. Each addresing a single change. Some of the proposed changes are declared untested. Some changes are controversial, like using a new environment variable PYTHONBROWSER prior to checking BROWSER. There are no references to this being discussed in python-dev. IMO this adds unecessary complexity, if the user is not satisfied with the BROWSER settings is easier and better to reconfigured it than to create a new variable. I recommend closing 954628. 728278 Multiple webbrowser.py bug fixes / improvements ------------------------------------------------------------------ Against the [http://python.org/patches/ Patch Submission Guidelines] this entry has uploaded both the whole file and .tgz, but no patch file. The large numbers of changes make it difficult to review. All the changes were documented to the top of the file, I don't believe they belong there. At least that is not complaint to the first rule in http://www.python.org/patches/style.html There are several OS X specific corrections that I'm unable to reproduce/validate, since I have no access to that platform. The modules was renamed to wingwebbrowser.py and the test case was built using this name. I believe this is inadequate, the original module name should be kept. There are three categories of changes: bug fixes, internal changes and interface changes. IMO it would be better to break this patch in at least three, matching these types of changes. Bug fixes would have a higher priority, less chance to break backward compatibility and more chance to be incorporated earlier. It should be applied before 1077979, otherwise that fix would be reversed. In spite of the formatting comments above, there are *valuable* changes in the submitted file. This is a nice candidate to be tackled in a Python Bug Day, since it functionality involves a broad range of platforms and user browsers preferences. Moreover, thourough test cases are hard to be cooked. I recommend keeping it open until somebody reshaped it properly and then applying it. 754022 Enhanced webbrowser.py -------------------------------------------------- This patch is properly formatted. I would change 'return 1' for 'return True', since this targets Py 2.4.x or above. It address some of the issues already addressed in entry 728278, since it proposes less changes and it is properly formatted I recommend applying it before 728278. 1166780 Fix _tryorder in webbrowser.py ----------------------------------------------------------- This is my own patch. At the present time (Py2.4) documentation says: """ Under Unix, if the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,... """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) But, when the environment variable BROWSER is messed up, there is no reason not to try the other detected browser alternatives. In this patch, if the BROWSER variable is Ok, than it is respected. Otherwise, the previously detected browsers are tryied out as if BROWSER variable never existed. This does not break backward compatibility and adds more chance for webbrowser.open() to succeed. This patch was made against CVS head 2005-03-20, and aims to 2.5, but can safely be apllied to any 2.4.x bug fix release. ---------------------------------- best regards, Rod Senra

2 1

Re: [Python-Dev] docstring before function declaration
by Nicholas Jacobson 22 Mar '05

22 Mar '05

Rule #1: If the docstring is the first line of a module, it's the module's docstring. Rule #2: If the docstring comes right before a class/function, it's that class/function's docstring. > How do you distinguish between a docstring at the > top of a module > that's immediately followed by a function? Is it > the module docstring > or the function docstring? It's both. The docstring would be assigned to both the module and the function. This is a *good* thing when there is a module with only one function in it. i.e. there should only be one docstring for both, and this saves repetition of that docstring. If a programmer wanted a docstring for the function but not the module, a blank first line would do the trick. A docstring for the module but not the function? Put a blank line between the module's docstring and the function. --Nick Jacobson __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

docstring before function declaration
by Nicholas Jacobson 21 Mar '05

21 Mar '05

IIRC, Guido once mentioned that he regretted not setting function docstrings to come before the function declaration line, instead of after. i.e. """This describes class Bar.""" class Bar: ... Or with a decorator: """This describes class Bar.""" @classmethod class Bar: ... Versus the current method: class Bar: """This describes class Bar.""" def foo: ... where the docstring looks like it refers to foo, not Bar. I think that commenting the function before its declaration, at the same tabbed point, increases the code's readability. What do you think about making this change at some point (e.g. Python 3000)? Or if not, then having the option to toggle to this layout? Thanks, --Nick Jacobson __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Re: [Python-checkins] python/dist/src/Lib/distutils/tests test_dist.py, 1.1, 1.2
by Thomas Heller 21 Mar '05

21 Mar '05

fdrake(a)users.sourceforge.net writes: > PEP 314 implementation (client side): I'm not sure where I should post this, but shouldn't there be a way to specify the encoding of the metadata? There are people (not me, fortunately), with umlauts in their names, for example. Thomas

3 2

Fwd: [Python-Dev] docstring before function declaration
by Eric Nieuwland 21 Mar '05

21 Mar '05

Nicholas Jacobson wrote: > IIRC, Guido once mentioned that he regretted not > setting function docstrings to come before the > function declaration line, instead of after. > > [ examples deleted ] > > I think that commenting the function before its > declaration, at the same tabbed point, increases the > code's readability. > > What do you think about making this change at some > point (e.g. Python 3000)? Or if not, then having the > option to toggle to this layout? Please don't. All class attributes are declared within the class. Pulling out the docstring would make it an exception. The current situation is very clear and easy to explain to newbies. If you feel the current position of the docstring may be the first attribute's docstring, insert a newline at the proper positions to separate the two. It works for me. --eric

1 0

Example workaround classes for using Unicode with csv module...
by Skip Montanaro 20 Mar '05

20 Mar '05

I added UnicodeReader and UnicodeWriter example classes to the csv module docs just now. They mention problems with ASCII NUL characters (which I vaguely remember - NUL-terminated strings are used internally, right?). Do NULs still present a problem? I saw nothing in the log messages that mentioned "ascii" or "nul" so I presume it is. Here's what I added. Let me know if you think it needs any corrections, especially if there's a better way to word "as long as you avoid encodings like utf-16 that use NULs". Can that just be "as long as you avoid multi-byte encodings other than utf-8"? I'd like to have something like this in the docs to demonstrate a reasonable workaround for the current no-Unicode code without casting it in stone by adding it to csv.py. -------------------------------------------------------------------------- The \module{csv} module doesn't directly support reading and writing Unicode, but it is 8-bit clean save for some problems with \ASCII{} NUL characters, so you can write classes that handle the encoding and decoding for you as long as you avoid encodings like utf-16 that use NULs. \begin{verbatim} import csv class UnicodeReader: def __init__(self, f, dialect=csv.excel, encoding="utf-8", **kwds): self.reader = csv.reader(f, dialect=dialect, **kwds) self.encoding = encoding def next(self): row = self.reader.next() return [unicode(s, self.encoding) for s in row] def __iter__(self): return self class UnicodeWriter: def __init__(self, f, dialect=csv.excel, encoding="utf-8", **kwds): self.writer = csv.writer(f, dialect=dialect, **kwds) self.encoding = encoding def writerow(self, row): self.writer.writerow([s.encode("utf-8") for s in row]) def writerows(self, rows): for row in rows: self.writerow(row) \end{verbatim} They should work just like the \class{csv.reader} and \class{csv.writer} classes but add an \var{encoding} parameter. -------------------------------------------------------------------------- Thx, Skip

2 1

python-dev Summary for 2005-03-01 through 2005-03-15 [draft]
by Brett C. 20 Mar '05

20 Mar '05

Amazingly on time thanks to the quarter being over. You can't see me jumping up and down in joy over that fact, but I am while trying not to hit the ceiling as I do it (for those of you who have never met me, I'm 6'6" tall, so jumping in a room is not always the smartest thing for me, especially when ceiling fans are involved). Since I will be on a plane most of tomorrow heading to DC for PyCon I won't get to this any sooner than Saturday while I am at the sprints. Might send it out Saturday or Sunday during a lull in the sprint, so please get corrections and additions in by then. -------------------------------------- ===================== Summary Announcements ===================== ----------------------------- Second to last summary for me ----------------------------- Just a reminder, after this Summary there is only one more left for me to write. After that Tim Lesher, Tony Meyer, and Steven Bethard will be taking over. ----------------- See you at PyCon! ----------------- PyCon_ is practically upon us! If you are going to be there, great! Please feel free to say hello if you run into me (will be at the sprints and the conference Wednesday and Thursday; skipping Friday to see a friend). Always happy to stop-and-chat. .. _PyCon: http://www.pycon.org/ ------------------------ 2.4.1 should be out soon ------------------------ Python 2.4.1c1 is out. Very shortly c2 will be released. Assuming no major issues come up, 2.4 final will be out. But in order to make sure no issues come up, we need the code to be tested! Please get the code and run the regression tests. If you are on a UNIX system it is as easy as running ``make test`` (``make testall`` is even better). The tests can also be run on non-UNIX systems; see http://docs.python.org/lib/regrtest.html on how. ========= Summaries ========= ---------------------- 2.4 should be out soon ---------------------- Python 2.4.1c1 was releaseed, but enough bugs were found and subsequently fixed that c2 release will occur before 2.4 final comes out. Contributing threads: - `2.4.1c1 March 10th, 2.4.1 March 17th <>`__ - `Failing tests: marshal, warnings <>`__ - `BRANCH FREEZE for 2.4.1rc1, 0000 UTC, 2005-03-10 <>`__ - `branch release24-maint is unfrozen, 2.4.1rc2? <>`__ - `os.access and Unicode <>`__ - `RELEASED Python 2.4.1, release candidate 1 <>`__ - `distutils fix for building Zope against Python 2.4.1c1 <>`__ - `Python2.4.1c1 and win32com <>`__ - `Open issues for 2.4.1 <>`__ ------------------------------------------- Getting state of all threads in interpreter ------------------------------------------- Florent Guillaume wrote some code for Zope that returned the current state of all threads in the interpreter, regardless of whether they were hung or not. Tim Peters suggested someone write up some code so that this could be made available in Python itself. Contributing threads: - `Useful thread project for 2.5? <>`__ --------------------------------- No new features in micro releases --------------------------------- A bug in os.access() not allowing Unicode strings triggered the discussion of whether it was a bugfix to repair the issue or a new feature. In the end it was decided it was a bugfix. But the point was specified that micro releases should never have any new feature, no matter how small. Contributing threads: - `[Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36 <>`__ - `No new features <>`__ - `os.access and Unicode <>`__ - `rationale for the no-new-features approach <>`__ ------------------------------------- Python wins Jolt "Productivity Award" ------------------------------------- Python was runner-up in the `15th annual Jolt Awards`_ in the category of "Languages and Development Environments", being given the "Productivity Award". Python is now award-winning. =) .. _15th annual Jolt Awards: http://www.sdmagazine.com/jolts/15th_jolt_finalists.html Contributing threads: - `FWD: SD MAgazine.com - Jolt Awards Winners <>`__ - `Python 2.4 won the "Jolt productivity award" last night <>`__ ------------------------------ New built-ins: any() and all() ------------------------------ Python 2.5 gains two new built-ins: any(), which returns True if the iterable passed to it contains any true items, and all(), which returns True if all the items in the iterable passed to it are true. Contributing threads: - `Adding any() and all() <>`__ -------------------------------- Abbreviating list comprehensions -------------------------------- The idea of allowing list comprehensions when the item being appended to the new list is passed directly in was proposed: ``[x in seq if f(x)`` would be equivalent to ``[x for x in seq if f(x)]``. The debate on this one is still going, but my gut says it won't be accepted; TOOWTDI and all. Contributing threads: - `Adding any() and all() <>`__ - `comprehension abbreviation <>`__ ------------------------- sum() semantics discussed ------------------------- Guido's blog entry on `the fate of reduce() in Python 3000`_ (which reiterated Guido's plan to cut map(), reduce(), filter() and lambdas (what about zip()?) caused a huge discussion on whether sum() worked the best way possible. As it stands now, sum() only accepts a sequence of numbers and its optional second argument works as an initial value to build off of. The suggestion was put forth of making the second argument more of a default argument if the passed-in sequence was empty. Otherwise the second argument would be ignored. But further discussion solidified the idea that sum() works quite well as it is and thus won't be changed in Python 3000. .. _the fate of reduce() in Python 3000: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 Contributing threads: - `sum() <>`__ - `Rationale for sum()'s design? <>`__ =============== Skipped Threads =============== + Re: python-dev Summary for 2005-01-16 through 2005-01-31 + Documentation for __new__ + Migrating to subversion + Decimal & returning NotImplemented (or not) + itemgetter/attrgetter extension + LinkedHashSet/LinkedHashMap equivalents + Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2 + code blocks using 'for' loops and generators + can we stop pretending _PyTyple_Lookup is internal? + (no subject) Thank you Michael Chermside for that very descriptive subject =)

6 7