[EMAIL PROTECTED] wrote]
>
> >> Changed now in CVS. When 2.4.2 is released it should be there.
>
> Trent> Is this the same kind of thing as the (generally ill-regarded)
> Trent> change in Python 2.2.x (for some x != 0) that added:
>
> No, I just backported the documentation bit that
>> Changed now in CVS. When 2.4.2 is released it should be there.
Trent> Is this the same kind of thing as the (generally ill-regarded)
Trent> change in Python 2.2.x (for some x != 0) that added:
No, I just backported the documentation bit that marked the keyword
parameter change to
[EMAIL PROTECTED] wrote]
> >> It does, in the "in-development" version of the documentation. Sorry it
> >> was not in the 2.4 releases :-(
>
> Thomas> Maybe it can be backported to 2.4.2 - is there still time for
> that?
>
> Changed now in CVS. When 2.4.2 is released it should be th
>> It does, in the "in-development" version of the documentation. Sorry it
>> was not in the 2.4 releases :-(
Thomas> Maybe it can be backported to 2.4.2 - is there still time for that?
Changed now in CVS. When 2.4.2 is released it should be there.
Skip
--
http://mail.python.org/ma
"Vinay Sajip" <[EMAIL PROTECTED]> writes:
> Thomas Heller wrote:
>> Yes, it seems so. Although I would have expected the documentation to
>> inform me about incompatible changes in the api.
>
> It does, in the "in-development" version of the documentation. Sorry it
> was not in the 2.4 releases :
Thomas Heller wrote:
> Yes, it seems so. Although I would have expected the documentation to
> inform me about incompatible changes in the api.
It does, in the "in-development" version of the documentation. Sorry it
was not in the 2.4 releases :-(
http://www.python.org/dev/doc/devel/lib/minimal
[EMAIL PROTECTED] wrote:
>Vinay> Well, it seems a little too late now, for unittest, threading,
> logging
>Vinay> and probably a few more.
>
>Correct, as I indicated.
>
>
...
>Vinay> What would you suggest for threading, unittest etc. in terms of
>Vinay> binding more unix_like_
Vinay> Well, it seems a little too late now, for unittest, threading,
logging
Vinay> and probably a few more.
Correct, as I indicated.
>> I realize I'm playing the devil's advocate here Still, a dual
>> naming scheme with the non-PEP-8 names deprecated should be possible.
Peter Otten <[EMAIL PROTECTED]> writes:
> Thomas Heller wrote:
>
>>> OK, it's not right at the top of the docs, but the example at
>>>
>>> http://docs.python.org/lib/minimal-example.html
>>>
>>> has been there for a while, and if you think it can be made clearer,
>>> please suggest how.
>>
>> May
Thomas Heller wrote:
>> OK, it's not right at the top of the docs, but the example at
>>
>> http://docs.python.org/lib/minimal-example.html
>>
>> has been there for a while, and if you think it can be made clearer,
>> please suggest how.
>
> Maybe I'm missing something, but the code from the exam
"Vinay Sajip" <[EMAIL PROTECTED]> writes:
> OK, it's not right at the top of the docs, but the example at
>
> http://docs.python.org/lib/minimal-example.html
>
> has been there for a while, and if you think it can be made clearer,
> please suggest how.
Maybe I'm missing something, but the code fr
[EMAIL PROTECTED] wrote:
> Since the logging package currently uses mixedCase it would appear it
> shouldn't revert to lower_case. I'm thinking it should have probably used
> lower_case from the start though. I see no real reason to have maintained
> compatibility with log4j. Similarly, I think
Trent Mick wrote:
> Yah. It was added before Guido more clearly stated that he thought
> modules should have a successful life outside the core before being
> accepted in the stdlib.
Perhaps so, but Guido was also quite keen to get PEP-282 implemented
for inclusion in 2.3, and pronounced on the c
[EMAIL PROTECTED] wrote:
> >> - It's a package, but contrary to any other package I've ever seen,
> >> most of its functionality is implemented in __init__.py.
>
> Trent> I'm not defending the implementation, but does this cause any
> Trent> particular problems?
>
> No, it just seems
[EMAIL PROTECTED] wrote:
> Perhaps so, but the logging module seems like such an unpythonic beast to
> me. How about cleaning it up (*) before we add more to it? Stuff like
> colorizing seems like it belongs in its own module (presuming a reasonably
> general markup scheme can be agreed upon) so
[EMAIL PROTECTED] wrote]
> Trent> I thought PEP 8 said camelCase (or whatever it is called) was
> Trent> okay?
>
> Hmmm... In the section entitled "Naming Conventions" I see:
>
> Function Names
>
> Function names should be lowercase, possibly with words separated by
> un
Trent> Unfortunately your getting caught by the default logging level
Trent> being WARN, so that any log level below that is tossed.
Ah, okay. I'll pick back through the docs and see what I missed, then maybe
add a description of the minimal steps needed to get going.
>> I suspect t
[EMAIL PROTECTED] wrote]
>
> >> - It's a package, but contrary to any other package I've ever seen,
> >> most of its functionality is implemented in __init__.py.
>
> Trent> I'm not defending the implementation, but does this cause any
> Trent> particular problems?
>
> No, it ju
>> - It's a package, but contrary to any other package I've ever seen,
>> most of its functionality is implemented in __init__.py.
Trent> I'm not defending the implementation, but does this cause any
Trent> particular problems?
No, it just seems symptomatic of some potential or
I recommend py.log (part of the py lib) as an example of a pythonic
implementation of logging. It uses a keyword-based mechanism and it
distinguishes between "producers" of log messages (i.e. your app) and
"consumers" of log messages (i.e. stdout, stderr, a database, a mail
server, etc.)
You can d
[EMAIL PROTECTED] wrote]
> Perhaps so, but the logging module seems like such an unpythonic beast to
> me. How about cleaning it up (*) before we add more to it?
Yes. I was also trying to encourage Rotem to get involved in other parts
of the logging module/package later on in my email. :)
> Stuf
>> while working on something in my current project I have made several
>> improvements to the logging package in Python, two of them are worth
>> mentioning:
...
Trent> Cool. Your additions sound useful.
Perhaps so, but the logging module seems like such an unpythonic beast t
[Rotem wrote]
> while working on something in my current project I have made several
> improvements to the logging package in Python, two of them are worth
> mentioning:
> 1. addition of a logging record field %(function)s, which results in
> the name
> of the entity which logged the record. My ver
Hi,
while working on something in my current project I have made several
improvements to the logging package in Python, two of them are worth
mentioning:
1. addition of a logging record field %(function)s, which results in
the name
of the entity which logged the record. My version even deduces the
24 matches
Mail list logo
