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
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 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
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 reasonable number of buildbots up and running.
A secondary problem is that it can be awkward to debug some of the
more obscure test failures on buildbots without having direct access
to the machine. From conversations on IRC, I don't think I'm alone in
wanting to find ways to make the buildbots more useful.
So the question is: how best to invest time and possibly money to
improve the buildbot situation (and as a result, I hope, improve the
quality of Python)? What could be done to make maintenance of build
slaves easier? Or to encourage interested third parties to donate
hardware and time? Are there good alternatives to Buildbot that might
make a difference? What do other projects do?
These are probably the wrong questions; I'm hoping that a discussion
would help produce the right questions, and possibly some answers.
Mark
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.
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 output parameters to stay without the const.
This is because adding the const to the input params will not break
existing code, but
adding const to output parameters may well require code changes for
users of the Python
API.
What is the best approach to this problem that will be acceptable?
Barry
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 that is why I have
written a profiler from scratch.
yappi is currently(v0.2) modifying the profilefunc variable fo the
ThreadState object to profile an exsiting thread. The newly created threads
are catched via threading.setprofile() call(from VM to our extension). And
for the deleted threads, we rely on the recycling of the ThreadState
objects.(Please see the website for details.)
I have tested it under a game server (100k players per-day) for about a
month for any issues and now releasing it.
Please see:
http://code.google.com/p/yappi/
Any thoughts/comments/ideas, anything?:)
--
Sumer Cip
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.
From what I gather by reading the archives on this list, the issue of
hostname checking seems controversial [3]. It seems widely admitted by
browser communities nowadays to check that the hostname the CN field of
the subject DN or the DNS entries of subjectAltName. I'd feel more
comfortable if this was the default behaviour of the client in Python's
SSL module, although having a mechanism to override this would be useful
indeed. It's more or less a basic security requirement to check the
identity of the server before doing anything else.
2. Cipher suite selection.
It's useful to restrict the list of cipher suites that can be used,
not just for speed (as mentioned in [1]), but also because some cipher
suites may be considered insecure by some institutions. This would be a
good feature to have indeed.
3. Full chain of certificates.
The PyOpenSSL module is able to take a callback function that
verifies each certificate in the chain (using depth). According to the
documentation, the ssl module only exposes the first certificate in the
chain (no CA). In some applications, it is useful to verify certain
policies according to attributes further up in the chain.
I'd like to suggest having an
"SSLSocket.getpeercerts(binary_form=False)" (plural) that returns a list
of certificates in the verification chain.
Is there a place where the status of the ssl module is summarized, or a
better place to discuss this? I could try to provide contributions or
further details if appropriate.
Best wishes,
Bruno.
[1] http://mail.python.org/pipermail/python-dev/2009-September/091636.html
[2] http://code.google.com/p/python-httpclient
[2] http://bugs.python.org/issue1589
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 good
to get some information about how useful the licenses have been, and how
they have helped people to improve Python's quality or ease of
distribution (if they have). I'm sure Microsoft would also appreciate
some positive feedback to their generosity, and I'll undertake to
provide that if this message elicits much by way of reply.
Since I'm pretty much too busy to follow the dev list right now I'd
appreciate direct Cc's.
regards
Steve
PS: If any further core developers need licenses, I plan to apply to
Microsoft again in the new year. I'll be sending out a message then, I
don't intend to keep a waiting list.
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Watch PyCon on video now! http://pycon.blip.tv/
[I wrote:]
> If Python3 were to have this feature it would make it worth
> migrating to
Sorry that may have sounded more harsh than I expected. If I had more
resources, I'd propose (and volunteer) a python3000 branch where any
and all who were disappointed at the *lack* of compatability changes
could continue working on the core language. (Moratorium controversy
solved and quaranteened--any desireable features for the working
branch would be back-propagated via the time machine as BDFL permits.)
marcos
