Mailman 3 October 2009 - Python-Dev

language summit topic: issue tracker
by Brett Cannon Nov. 3, 2009

Nov. 3, 2009

Another summit, another potential time to see if people want to change anything about the issue tracker. I would bring up: - Dropping Stage in favor of some keywords (e.g. 'needs unit test', 'needs docs') - Adding a freestyle text box to delineate which, if any, stdlib module is the cause of a bug and tie that into Misc/maintainers.rst; would potentially scale back the Component box -Brett

8 11

thanks to everyone cleaning up the tests
by Brett Cannon Nov. 3, 2009

Nov. 3, 2009

Just wanted to publicly thank everyone who has been causing all the checkins to fix and stabilize the test suite (I think it's mostly Antoine and Mark, but I could be missing somebody; I'm under a deadline so only have marginal higher brain functionality). -Brett

4 3

A new way to configure logging
by Vinay Sajip Nov. 2, 2009

Nov. 2, 2009

At present, configuration of Python's logging package can be done in one of two ways: 1. Create a ConfigParser-readable configuration file and use logging.config.fileConfig() to read and implement the configuration therein. 2. Use the logging API to programmatically configure logging using getLogger(), addHandler() etc. The first of these works for simple cases but does not cover all of the logging API (e.g. Filters). The second of these provides maximal control, but besides requiring users … [View More]to write the configuration code, it fixes the configuration in Python code and does not facilitate changing it easily at runtime. In addition, the ConfigParser format appears to engender dislike (sometimes strong dislike) in some quarters. Though it was chosen because it was the only configuration format supported in the stdlib at that time, many people regard it (or perhaps just the particular schema chosen for logging's configuration) as 'crufty' or 'ugly', in some cases apparently on purely aesthetic grounds. Recent versions of Python of course support an additional battery-included format which can be used for configuration - namely, JSON. Other options, such as YAML, are also possible ways of configuring systems, Google App Engine-style, and PyYAML has matured nicely. There has also been talk on the django-dev mailing list about providing better support for using Python logging in Django. When it happens (as of course I hope it does) this has the consequence that many new users who use Django but are relatively inexperienced in Python (e.g. in PHP shops which are moving to Django) will become exposed to Python logging. As Django is configured using a Python module and use of ConfigParser-style files is not a common approach in that ecosystem, users will find either of the two approaches outlined above a particular pain point when configuring logging for their Django applications and websites, unless something is done to avoid it. All three of the contenders for the title of "commonly found configuration mechanism" - JSON, YAML and Python code - will be expressible, in Python, as Python dicts. So it seems to make sense to add, to logging.config, a new callable bound to "dictConfig" which will take a single dictionary argument and configure logging from that dictionary. An important facet of implementing such a scheme will be the format or schema which the dictionary has to adhere to. I have started working on what such a schema would look like, and if people here think it's a good idea to go ahead with this, I'll provide the details of the schema on a separate post which I'll also cross-post on comp.lang.python so that I can get feedback from there, too. In outline, the scheme I have in mind will look like this, in terms of the new public API: class DictConfigurator: def __init__(self, config): #config is a dict-like object (duck-typed) import copy self.config = copy.deepcopy(config) def configure(self): # actually do the configuration here using self.config dictConfigClass = DictConfigurator def dictConfig(config): dictConfigClass(config).configure() This allows easy replacement of DictConfigurator with a suitable subclass where needed. What's the general feeling here about this proposal? All comments and suggestions will be gratefully received. Regards, Vinay Sajip [View Less]

6 16

Possible language summit topic: buildbots
by Mark Dickinson Nov. 2, 2009

Nov. 2, 2009

Would it be worth spending some time discussing the buildbot situation at the PyCon 2010 language summit? In the past, I've found the buildbots to be an incredibly valuable resource; especially when working with aspects of Python or C that tend to vary significantly from platform to platform (for me, this usually means floating-point, and platform math libraries, but there are surely many other things it applies to). But more recently there seem to have been some difficulties keeping a … [View More]

15 71

"Buildbot" category on the tracker
by Antoine Pitrou Oct. 31, 2009

Oct. 31, 2009

Hello, What do you think of creating a "buildbot" category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Regards Antoine.

5 17

Add const to python API - issue 6952
by Barry Scott Oct. 31, 2009

Oct. 31, 2009

http://bugs.python.org/issue6952 Martin v. Löwis suggested that solutions to this issue should be discussed here. My goal is to avoid compiler warning and the need to cast to remove const when calling the python API. For example I see compiler messages like this on Mac OS X Snow Leopard g++ reports: example.cxx:633: warning: deprecated conversion from string constant to ‘char*’ The patch I developed for comment only adds const to the input parameters and used casts to allow … [View More]

3 6

Summary of Python tracker Issues
by Python tracker Oct. 30, 2009

Oct. 30, 2009

ACTIVITY SUMMARY (10/23/09 - 10/30/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. 2483 open (+31) / 16582 closed (+19) / 19065 total (+50) Open issues with patches: 989 Average duration of open issues: 675 days. Median duration of open issues: 430 days. Open Issues Breakdown open 2447 (+31) pending 35 ( +0) Issues Created Or Reopened (53) … [View More]

1 0

yappi - any thoughts?
by Sümer Cip Oct. 30, 2009

Oct. 30, 2009

Hi there, yappi(Yet Another Python Profiler) is a multithreaded profiler for 2.x series(do not know if it will work on 3k, not tested yet). I have done my best to make it efficient as possible.(details are under the technical bullet in the website). It is aimed for long-running programs, to attach/detach profiler and retrieve stats on the fly. The current cProfile module needs substantial amount of work to accomplish this task and also have some problems with recursive functions, basically … [View More]

2 1

ssl module
by Bruno Harbulot Oct. 30, 2009

Oct. 30, 2009

Hello, I would like to ask a few questions and suggestions regarding the ssl module (in Python 2.6). (I gather from [1] that there is some effort going on to enhance the ssl API, but I'm not sure if this is the right place to discuss it.) Like other Python users, I was a bit surprised by the lack of verification of httplib/urllib2 (hence I started to write a small library a while back, only published today [2]), but the following points are not HTTP-specific. 1. Hostname checking. … [View More]

3 2

MSDN subscribers: Using Visual Studio?
by Steve Holden Oct. 29, 2009

Oct. 29, 2009

I just wondered, with the recent flood of new MSDN subscriptions loosed on the developer community, how many people have installed the required version of Visual Studio and built Python for Windows from source? Not being that familiar with the process myself I was hoping for some advice from the inexperienced who have overcome any hurdles there might be. I have a pristine virtual machine just waiting for the right pieces ... Also what other uses have you found for the licenses? It would be … [View More]

4 3