[Python-ideas] Logging2 with default NullHandler

[anatoly techtonik]

On Sun, Mar 18, 2012 at 10:54 AM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> On Sat, Mar 17, 2012 at 1:03 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> problem required a lot of effort alone. If there was a list for known
>> misbehaviours like this in Python 2.x the things could be much easier.
>
> If you don't find it on the tracker (including closed issues), for the
> purpose of
> actually getting it changed, it's unknown.

The problem that it is almost impossible to find anything on tracker
related to specific component like logging. The issue description
doesn't always correspond to the actual content and it is really hard
to get through all the comments. Proposal - add modules field, allow
comment rating, issue and commend edits (Trac). Why won't I do
anything? Because my time is limited to 15 minutes slots and getting
developer instance takes more time, so I never pass through this
barrier (and TAL is not my language).

>> I guess the question can be closed, but I am still dissatisfied with
>> the current state of things.
>
> So fix it.  If you didn't find an open issue on the tracker, that means either
> few people (== 0) care enough to post an issue at all, or, as far as those
> who care are concerned, it's already fixed in the relevant branch(es) and
> the issue has been closed.  Either way, you're going to have to do it yourself.
>
>> If Python 3.x is developed using the same process, there is a risk
>> of UX problems like this too.
>
> There's always a risk of problems.  Do you have a specific proposal for
> improving process?

The first step is to gather a critical mass of people who acknowledge
the problem, who have their own ideas summarized and can share them at
the right moment. So, the specific proposal is to have a history that
can be analyzed by anyone. Right now it is extremely hard to summarize
problems - no custom tags on tracker, no way to organize email threads
- these are just two technical proposals to improve the process. One
more idea is the use case DB to collect API uses cases and detect
conflicts at early stage to draw attention to them. Every problem and
use case should have a number, should be clearly defined (much better
than tracker issue summaries) and should have a rating/star system.
That should be enough for now.
--
anatoly t.