Mailman 3 May 2009 - Python-Dev

[Fwd: [Python-checkins] r72331 - python/branches/py3k/Modules/posixmodule.c]
by Eric Smith May 5, 2009

May 5, 2009

Modules/posixmodule.c now compiles for me, but I get a Bus Error in test_lchflags when running test_posixmodule on Mac OS X 10.5. I'll open a release blocker bug on this. -------- Original Message -------- Subject: [Python-checkins] r72331 - python/branches/py3k/Modules/posixmodule.c Date: Tue, 5 May 2009 15:07:31 +0200 (CEST) From: eric.smith <python-checkins(a)python.org> To: python-checkins(a)python.org Author: eric.smith Date: Tue May 5 15:07:30 2009 New Revision: 72331 Log: … [View More]

1 0

PEP 383 and GUI libraries
by "Martin v. Löwis" May 5, 2009

May 5, 2009

I checked how GUI libraries deal with half surrogates. In pygtk, a warning gets issued to the console /tmp/helloworld.py:71: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text() self.window.show() and then the widget contains three crossed boxes. wxpython (in its wxgtk version) behaves the same way. PyQt displays a single square box. Regards, Martin

12 17

turtle.py update for 3.1
by Gregor Lingl May 4, 2009

May 4, 2009

Hi, Encouraged by a conversation with Martin at PyCon 2009 I've prepared a version 1.1b of the turtle module and I'd like to get some advice or assistance to get it into the beta as explained below. Thus I'd appreciate very much if also the release manager would take notice of this posting. python 2.0 had the version 1.0 and for now I'll give a terse summary of the changes I did: 1. a few bugfixes, with 1 - 5 lines of code changed for each; these concern bugs that prevented turtle to run … [View More]correctly 2. I've added four methods to the class TurtleScreeenBase: _onkeypress(fun, key) (supplementing _onkeyrelease) mainloop() (which is now a Screen-method and a function) textinput(title, prompt) numinput(title, prompt, default, minval, maxval) the latter two remedy the complete lack of input methods _onkey, an internal method name is changed to _onkeyrelease 3. I've added one method to the class TurtleScreen: onkeypress(fun, key=None) implemented in analogy to the already present onkey() which got onkeyrelease as an alias. 4. I've changed several portions of the code that affect the representation of the turtleshape thus making it more compact (by removing some duplicated code) and more powerful, i. e. by adding the possibility to apply shearings to turtleshapes (in addition to the already present scaling and rotating transformations). Thus now the full range of (non singular) linear transformations is available. New methods in class RawTurtle: shearfactor(shear=None) set or get the shearfactor shapetransform(t11, t12, t21, t22) set or get the shape transform directly get_shapepoly() return the polygon of the current shape I've enhanced the functionality of tiltangle(angle=None) to contain also that of settiltangle and I propose to declare settiltangle as deprecated. 5. I've removed a lot of codelines that were commented out during the process of transferring the module from 2.6 to 3.0 6. I've implemented the bugfix for http://bugs.python.org/issue4117 according do my proposition there and I strongly recommend this change again, as the bug described is very annoying, the fix is easy and no one proposed a better solution. 7. I've tested the present version 1.1 extensivly. It runs all the demo scripts without problems and many others too (some of them significantly better than version 1.1). I'd like to add two additional scripts to the demo directory, one of them using new features so it only runs with this new version. I've *not* touched the issue of the Screen singleton, so that remains unchanged as it was as a result of Martins patch. Thus, as a summary, this update does some bugfixes and eliminates three deficiencies of the module: (1) accept keypress event, (2) provide user input functions and (3) complement scaling and rotating of turtleshapes by shearing, thus providing the full range of linear transforms. HOW TO PROCEED NOW? (1) Submit the new version as a single file (2) submit a unified diff containing all the changes (3) Divide the changes into several chunks of related changes and submit the according diffs separately That would pose the problems, that there are lines in the code that are affected by several changes, e. g. those lines that define __all__ And also: does the order of applying the patches matter? How do I have to account for this? (4) Some other approach? I'd appreciate to discuss open issues as needed and I'm prepared to give more elaborate explanations and rationales as wanted or as needed. Docs for the changes are (to a large extent) contained in the docstrings and I'm going to update the Documentation of the turtle module (on the basis of theses docstrings) now. Thanks in advance for your support Gregor [View Less]

2 1

RFC: Threading-Aware Profiler for Python
by Christian Schubert May 4, 2009

May 4, 2009

Hi, Python ships with a profiler module which, unfortunately, is almost useless in a multi-threaded environment. * I've created an alternative profiler module which queries per-thread CPU usage via netlink/taskstats, which limits the applicability to Linux (which shouldn't be much of an issue, profiling is usually not done by end users). It implements two modes: a "sampling" (does CPU time accounting based on stack fraames 100 times per second, by default) and a "deterministic" profiler (does … [View More]CPU time accounting on each function call/return, based on sys.profiler interface). The deterministic profiler is currently implemented in pure python (except for taskstats interface) and much slower than the sampling profiler. Usage (don't forget make to build the c module): python >> from Profiler import * >> def f(): do_something() >> sampling_profiler(f) or >> deterministic_profiler(f) Output is currently in the form of annotated source code (xyz.py.html, in the same directory where xyz.py resides). Before the *_profiler function returns, it iterates over all code objects it encountered and annotates the source files with 2 columns in front: - 1st column: real time - 2nd column: CPU time numbers are log2(time_in_ns), colors are green-to-yellow for below-average and yellow-to-red for above-average metrics (relative to the average metric for all lines of the code object with a metric > 0). Is there common need for such a module? Is it possible to have this included in the standard cPython distribution? Which functional changes (besides a modification of the annotation output which shouldn't spread its result all over the FS) would be required to get this included? Which non-functional changes would be required to get this included? Please direct traffic regarding this subject to pyprof-devel(a)lists.sourceforge.net (no I'm not subscribed to python-dev). SF project page: https://sourceforge.net/projects/pyprof/ git repository: git://pyprof.git.sourceforge.net/gitroot/pyprof Regards, Christian *) to be more exact there are at least three profiler modules: profile, cProfile, and hotshot, while I did only try (and failed) to use profile in a multi-threaded environment (by manually setting threading.profile to the profiling function), glancing at the source, I'm pretty sure that cProfile behaves similarly; I didn't test the hotshot module, but it does some other trade-offs (space-for-time), so I think that "pyprof" still adds some value [View Less]

5 4

PyPI copyright
by Oleg Broytmann May 4, 2009

May 4, 2009

http://pypi.python.org/pypi "Copyright © 1990-2007, Python Software Foundation" :s/2007/2009/ Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

1 0

Changing float.__format__
by Eric Smith May 4, 2009

May 4, 2009

In issue 5920, Mark Dickinson raises an issue having to do with float.__format__ and how it handles the default format presentation type (that is, none of 'f', 'g', or 'e') versus how str() works on floats: http://bugs.python.org/issue5920 I agree with him that the current behavior is confusing and should be changed. I'm going to make this change, unless anyone objects. Please comment on the issue itself if you have any feedback. Eric.

1 0

PEP 383 and GUI libraries
by Jim Jewett May 4, 2009

May 4, 2009

(sent only to python-dev, as I am not a subscriber of tahoe-dev) Zooko wrote: > [Tahoe] currently uses utf-8 for its internal storage (note: nothing to > do with reading or writing files from external sources -- only for > storing filenames in the decentralized storage system which is > accessed by Tahoe clients), and we can't start putting non-utf-8-valid > sequences in the "filename" slot because other Tahoe clients would > then get a UnicodeDecodeError exception when … [View More]

1 0

yield from?
by Benjamin Peterson May 3, 2009

May 3, 2009

What's the status of yield from? There's still a small window open for a patch to be checked into 3.1's branch. I haven't been following the python-ideas threads, so I'm not sure if it's ready yet. -- Regards, Benjamin

3 4

multi-with statement
by Georg Brandl May 3, 2009

May 3, 2009

Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over "with A(), B() as a, b:") because it has more syntactical similarity to the written-out version. Also, our current uses of "as" all have only one expression on the right. The patch … [View More]

5 5

Oddity PEP 0 key
by MRAB May 2, 2009

May 2, 2009

I've just noticed an oddity in the key in PEP 0. Most letters are used more than once. Wouldn't it be clearer if different letters were used for "Accepted" and "Active" instead of them both being 'A', for example? -> A - Accepted proposal -> R - Rejected proposal W - Withdrawn proposal -> D - Deferred proposal F - Final proposal -> A - Active proposal -> D - Draft proposal -> R - Replaced proposal

10 13

FWD: svn down?
by Aahz May 2, 2009

May 2, 2009

----- Forwarded message from "\"Martin v. L?wis\"" <martin(a)v.loewis.de> ----- > Date: Sat, 02 May 2009 08:18:56 +0200 > From: "\"Martin v. L?wis\"" <martin(a)v.loewis.de> > To: Aahz <aahz(a)pythoncraft.com> > CC: pydotorg(a)python.org > Subject: Re: [Pydotorg] FWD: [Python-Dev] svn down? > >> Benjamin Peterson reports being unable to ssh to dinsdale > > I have rebooted the machine; it seems now to be working again. > > Regards, > … [View More]

1 0

svn down?
by Eric Smith May 1, 2009

May 1, 2009

When checking in, I get: Transmitting file data .svn: Commit failed (details follow): svn: Can't create directory '/data/repos/projects/db/transactions/72186-1.txn': Read-only file system With 'svn up', I get: svn: Can't find a temporary directory: Internal error

2 1

Dropping bytes "support" in json
by Antoine Pitrou May 1, 2009

May 1, 2009

Hello, We're in the process of forward-porting the recent (massive) json updates to 3.1, and we are also thinking of dropping remnants of support of the bytes type in the json library (in 3.1, again). This bytes support almost didn't work at all, but there was a lot of C and Python code for it nevertheless. We're also thinking of dropping the "encoding" argument in the various APIs, since it is useless. Under the new situation, json would only ever allow str as input, and output str as well. … [View More]

34 120

Summary of Python tracker Issues
by Python tracker May 1, 2009

May 1, 2009

ACTIVITY SUMMARY (04/24/09 - 05/01/09) 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. 2190 open (+34) / 15527 closed (+29) / 17717 total (+63) Open issues with patches: 861 Average duration of open issues: 645 days. Median duration of open issues: 394 days. Open Issues Breakdown open 2156 (+33) pending 33 ( +1) Issues Created Or Reopened (63) … [View More]

1 0

Deferring PEP 382
by "Martin v. Löwis" May 1, 2009

May 1, 2009

During Guido's review, we discovered that PEP 382 doesn't deal with PEP 302 loaders; I believe that it should, though. Rather than coming up with an ad-hoc design, I propose to defer the PEP to Python 3.2 - unless somebody can propose a straight-forward design with not too many new interfaces. FWIW, my own approach would be to add two new interfaces to loaders: 1. extend the package path according to .pth files available to the loader (alternatively, provide the contents of the .pth … [View More]

1 0