Mailman 3 October 2008 - Python-Dev

Backporting multiprocessing?
by Skip Montanaro Oct. 22, 2008

Oct. 22, 2008

I'd like to try backporting the multiprocessing module to Python 2.4. My first problem appears to be the reliance on a complete(?) rewrite of the buffer stuff. Any clues about transforming this code would be much appreciated. (Note: I'm backporting because the Python 2.6 version appears to be much more robust than the 0.52 third-party release.) Thanks, Skip

5 11

Re: [Python-Dev] [Csv] skipfinalspace
by Tom Brown Oct. 21, 2008

Oct. 21, 2008

(Continuing thread started at http://mail.python.org/pipermail/csv/2008-October/000688.html) On Sun, Oct 19, 2008 at 16:46, Andrew McNamara <andrewm(a)object-craft.com.au>wrote: > >I downloaded the 2.6 source tar ball, but is it too late for new features > to > >get into versions <3? > > Yep. > > >How would you feel about adding the following tests to > Lib/test/test_csv.py > >and getting them to pass? > > > >Also http://www.python.… [View More]

4 3

Re: [Python-Dev] [Csv] skipfinalspace
by Tom Brown Oct. 21, 2008

Oct. 21, 2008

On Mon, Oct 20, 2008 at 00:48, John Machin <sjmachin(a)lexicon.net> wrote: > Tom Brown wrote: > >> (Continuing thread started at >> http://mail.python.org/pipermail/csv/2008-October/000688.html) >> >> On Sun, Oct 19, 2008 at 16:46, Andrew McNamara < >> andrewm(a)object-craft.com.au <mailto:andrewm@object-craft.com.au>> wrote: >> >> >I downloaded the 2.6 source tar ball, but is it too late for new >> features to &… [View More]gt;> >get into versions <3? >> >> Yep. >> >> >How would you feel about adding the following tests to >> Lib/test/test_csv.py >> >and getting them to pass? >> > >> >Also http://www.python.org/doc/2.5.2/lib/csv-fmt-params.html says >> >"*skipinitialspace *When True, whitespace immediately following the >> >delimiter is ignored." >> >but my tests show whitespace at the start of any field is ignored, >> including >> >the first field. >> >> I suspect (but I haven't checked) that it means "after the delimiter >> and >> before any quoted field (or some variation on that). >> >> I agree that whitespace after the delimiter and before any quoted field is >> skipped. Also whitespace after the start of the line and before any quoted >> field is skipped. >> > > All of the "dialect" parameters are there to allow parsing of a >> specific >> common form of CSV file. Because there is no formal definition of the >> format, the module simply aims to parse (and produce the same result) >> as common applications such as Excel and Access. Changing the behaviour >> in any non-backwards compatible way is sure to get screams of anguish >> from many users. Even when the behaviour appears to be a bug, you can >> be sure people are counting on it working like that. >> >> >> skipinitialspace defaults to false and by the same logic skipfinalspace >> should default to false to preserve compatibility with the csv module in >> 2.6. On the other hand, the switch to version 3 is as good a time as any to >> break backwards compatibility to adopt something that works better for new >> users. >> > > Read Andrew's lips: They don't want "better", they want "the same as MS". okay. > > > Based on my experience parsing several hundred csv generated by many >> different people I think it would be nice to at least have a dialect that is >> excel + skipinitialspace=True + skipfinalspace=True. >> > > Based on my experience extracting data from innumerable csv files (and > infinite varieties thereof), Wow, that is a _lot_ of files :-P spreadsheet files, and database tables, in 99.99% of cases one should > automatically apply the following transformations to each text field: > * strip leading whitespace > * strip trailing whitespace > * replace embedded runs of whitespace by a single space > and one needs to ensure that the definition of whitespace includes the > no-break space (NBSP) character. > > As this "space normalisation" is needed for all input sources, the csv > module is IMHO the wrong place to put it. A string method would be a better > idea. I agree that strip() and something like re.sub(r"\s+", " " are handy. If 99.99% percent of csv readers should be applying these fixes to every field perhaps there should be easy-to-enable option to apply it. Why force almost everyone to discover they need the transformations and put a line of code around csv reader? [View Less]

1 0

Old green snake icon on Windows
by Gregor Lingl Oct. 17, 2008

Oct. 17, 2008

I've installed the new Python 2.6 for windows (Windows-installer) on several machines among them a new one which has never seen Python before and all these installations show the old fashioned green snake logo (from Python 2.3 or before, I think) in the automatically created menu-entries. Has anybody else observed this? What could be the reason for this? Is this intentional, and if so what is the intention? Or is there something wrong with the installer? (I even cannot change the icons … [View More]

2 1

Summary of Python tracker Issues
by Python tracker Oct. 17, 2008

Oct. 17, 2008

ACTIVITY SUMMARY (10/10/08 - 10/17/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2104 open (+21) / 13859 closed (+19) / 15963 total (+40) Open issues with patches: 689 Average duration of open issues: 714 days. Median duration of open issues: 1891 days. Open Issues Breakdown open 2088 (+21) pending 16 ( +0) Issues Created Or Reopened (41) … [View More]

1 0

Re: [Python-Dev] [Python-3000] Backporting multiprocessing?
by Jesse Noller Oct. 17, 2008

Oct. 17, 2008

Do we want to start a google code project for this given all three of us are interested in this? :) On Thu, Oct 16, 2008 at 3:28 PM, Christian Heimes <lists(a)cheimes.de> wrote: > Skip Montanaro wrote: >> >> I'd like to try backporting the multiprocessing module to Python 2.4. My >> first >> problem appears to be the reliance on a complete(?) rewrite of the buffer >> stuff. >> >> Any clues about transforming this code would be much … [View More]

3 5

Re: [Python-Dev] [Python-3000] Backporting multiprocessing?
by skip＠pobox.com Oct. 17, 2008

Oct. 17, 2008

Christian> I like to make as much code of the trunk version compatible Christian> with 2.5 and 2.4 as possible. Let's see how far we can get Christian> with a bunch of macros and #ifdefs. I'll follow your lead. ;-) Skip

1 0

Documentation idea
by Raymond Hettinger Oct. 16, 2008

Oct. 16, 2008

Background ---------- In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for any() and all(). The new collections.namedtuple() factory function also includes a verbose option that prints a pure python equivalent for the generated class. And in the decimal module, I took examples directly from the … [View More]spec and included them in doc-testable docstrings. This assured compliance with the spec while providing clear examples to anyone who bothers to look at the docstrings. For itertools docs, I combined those best practices and included sample calls in the pure-python code (see the current docs for itertools to see what I mean -- perhaps look at the docs for a new tool like itertools.product() or itertools.izip_longest() to see how useful it is). Bright idea ---------- Let's go one step further and do this just about everywhere and instead of putting it in the docs, attach an exec-able string as an attribute to our C functions. Further, those pure python examples should include doctests so that the user can see a typical invocation and calling pattern. Say we decide to call the attribute something like ".python", then you could write something like: >>> print(all.python) def all(iterable): '''Return True if all elements of the iterable are true. >>> all(isinstance(x, int) for x in [2, 4, 6.13, 8]) False >>> all(isinstance(x, int) for x in [2, 4, 6, 8]) True ''' for element in iterable: if not element: return False return True There you have it, a docstring, doctestable examples, and pure python equivalent all in one place. And since the attribute is distinguished from __doc__, we can insist that the string be exec-able (something we can't insist on for arbitrary docstrings). Benefits -------- * I think this will greatly improve the understanding of tools like str.split() which have proven to be difficult to document with straight prose. Even with simple things like any() and all(), it makes it self-evident that the functions have early-out behavior upon hitting the first mismatch. * The exec-able definitions and docstrings will be testable * It will assist pypy style projects and other python implementations when they have to build equivalents to CPython. * We've gotten good benefits from doctests for pure python functions, why not extend this best practice to our C functions. * The whole language will become more self-explanatory and self-documenting. * Will eliminate confusion about what functions were exactly intended to do. * Will confer benefits similar to test driven development where the documentation and pure python version are developed first and doctests gotten to pass, then the C version is created to match. * For existing code, this is a perfect project for people who want to start contributing to the language but aren't ready to start writing C (the should be able to read C however so that the equivalent really does match the C code). Limits ----- * In some cases, there may be no pure python equivalent (i.e. sys.getsize()). * Sometimes the equivalent can only be approximate because the actual C function is too complex (i.e. itertools.tee()). * Some cases, like int(), are useful as a type, have multiple functions, and are hard to write as pure python equivalents. * For starters, it probably only makes to do this for things that are more "algorithmic" like any() and all() or things that have a straight-forward equivalent like property() written using descriptors. Premise ------- Sometimes pure python is more expressive, precise, and easy to read than English prose. [View Less]

10 18

www.python.org/doc and docs.python.org hotfixed
by Thomas Wouters Oct. 15, 2008

Oct. 15, 2008

I hotfixed docs.python.org and www.python.org/doc with some cutesy improv -- the URLs changed from .../lib/ to ../library/, and any HTML pages inside them are completely different. So, any http://docs.python.org/lib/... URL now redirects to the toplevel http://docs.python.org/library/ (and similar for www.python.org/doc/lib.) If anyone feels particularly frustrated by the old URLs breaking, I wouldn't mind adding a redirection for each individual URL as long as I don't have to build that … [View More]

10 24

Re: [Python-Dev] [pygtk] Application name is '-c'
by Greg Ewing Oct. 14, 2008

Oct. 14, 2008

Frédéric wrote: > In several places, instead of having my application name, I get '-c'. This could be a result of the app having got launched via 'python -c' somewhere along the way: % python -c 'import sys; print sys.argv[0]' -c Not sure whether to regard this as a bug or not. It's not clear what the app name *should* be when you use -c. What do the python-dev folks think? -- Greg

2 1