Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #19110 > unrolled thread

Re: python logging filter limitation, looks intentional?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: python logging filter limitation, looks intentional? Terry Reedy <tjreedy@udel.edu> - 2012-01-18 19:50 -0500
    Re: python logging filter limitation, looks intentional? Vinay Sajip <vinay_sajip@yahoo.co.uk> - 2012-01-20 11:17 -0800
      Re: python logging filter limitation, looks intentional? Terry Reedy <tjreedy@udel.edu> - 2012-01-20 15:09 -0500
      Re: python logging filter limitation, looks intentional? Chris Withers <chris@simplistix.co.uk> - 2012-01-28 10:51 +0000
        Re: python logging filter limitation, looks intentional? Vinay Sajip <vinay_sajip@yahoo.co.uk> - 2012-01-29 02:07 -0800

#19110 — Re: python logging filter limitation, looks intentional?

On 1/18/2012 4:02 PM, Chris Withers wrote:
> On 17/01/2012 10:48, Vinay Sajip wrote:

> How about an option that defaults to "backwards compatibility mode" for
> Python 2.7, flipped the other way in 3.3?

2.7 only gets bug fixes, and this does not seem to be one.

>> It's not a bug, because it's like that by design. I understand that
>> you don't agree with that particular design decision, but it's out
>> there now. What you're asking for isn't unreasonable, but not
>> achievable without a change in behaviour.
>
> See above ;-)
>
>> I don't want people to have to code differently for Python 3.3 and for
>> older versions.

This is not a general policy, else we would never add new features ;-)
Do you plan to keep logging feature-frozen forever, or just for another 
release? (I actually think is a good idea to fix bugs, tests, and docs 
first.)

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#19162

On Jan 19, 12:50 am, Terry Reedy <tjre...@udel.edu> wrote:
>
> >> I don't want people to have to code differently for Python 3.3 and for
> >> older versions.
>
> This is not a general policy, else we would never add new features ;-)
> Do you plan to keep logging feature-frozen forever, or just for another
> release? (I actually think is a good idea to fix bugs, tests, and docs
> first.)

Logging isn't by any means feature-frozen - new features are being
added all the time, including non-trivial additions made in 2.7 and
3.2, and some more changes planned for 3.3 and already checked in. My
comment was about the specific change proposed, which if implemented
could lead to existing working third party code failing after a Python
version upgrade. The proposed change isn't a new feature, it's a
request for an existing feature to work differently.

Apart from the behavioural change, there is also a performance
implication which needs to be considered. All in all, I'm not sure
there is a lot of demand for this proposed change, and I have already
suggested a workable approach to Chris which should meet his needs
without any need for a behavioural change in the standard library.

Regards,

Vinay Sajip

[toc] | [prev] | [next] | [standalone]

#19164

On 1/20/2012 2:17 PM, Vinay Sajip wrote:
> On Jan 19, 12:50 am, Terry Reedy<tjre...@udel.edu>  wrote:
>>
>>>> I don't want people to have to code differently for Python 3.3 and for
>>>> older versions.
>>
>> This is not a general policy, else we would never add new features ;-)
>> Do you plan to keep logging feature-frozen forever, or just for another
>> release? (I actually think is a good idea to fix bugs, tests, and docs
>> first.)
>
> Logging isn't by any means feature-frozen - new features are being
> added all the time, including non-trivial additions made in 2.7 and
> 3.2, and some more changes planned for 3.3 and already checked in. My
> comment was about the specific change proposed, which if implemented
> could lead to existing working third party code failing after a Python
> version upgrade. The proposed change isn't a new feature, it's a
> request for an existing feature to work differently.

Thank you for the clarification. I had not gotten that the request was 
for a change, which has a much higher bar to pass than feature 
additions. I was thinking of 'code differently' as in

if sys.version.split()[0] >= '3.3': <use snazzy new feature>
else: <use klutzy old workaround>

but that is not a 'have to' as long as the workaround still works.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#19546

On 20/01/2012 20:09, Terry Reedy wrote:
>> version upgrade. The proposed change isn't a new feature, it's a
>> request for an existing feature to work differently.
>
> Thank you for the clarification. I had not gotten that the request was
> for a change, which has a much higher bar to pass than feature
> additions.

To be clear, I wasn't asking for a change to existing behaviour, I was 
asking for the addition of an option that would allow the logging 
framework to behave as most people would expect when it comes to filters ;-)

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

[toc] | [prev] | [next] | [standalone]

#19582

On Jan 28, 10:51 am, Chris Withers <ch...@simplistix.co.uk> wrote:

> To be clear, I wasn't asking for a change to existing behaviour, I was
> asking for the addition of an option that would allow thelogging
> framework to behave as most people would expect when it comes to filters ;-)

And the evidence for "most people" would be ... ? ;-) It hasn't been
raised before, despite filters working the way they do since Python
2.3 ...

And I wonder, would any of those people be willing to accept the
performance impact of the change? I'm not sure how big the impact
would be, but it does involve another hierarchy traversal and
additional calls to the ancestor filters.

Regards,

Vinay Sajip

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web