python logging filter limitation, looks intentional?
Terry Reedy
tjreedy at udel.edu
Fri Jan 20 15:09:31 EST 2012
More information about the Python-list mailing list
Fri Jan 20 15:09:31 EST 2012
- Previous message (by thread): python logging filter limitation, looks intentional?
- Next message (by thread): python logging filter limitation, looks intentional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 1/20/2012 2:17 PM, Vinay Sajip wrote: > On Jan 19, 12:50 am, Terry Reedy<tjre... at 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
- Previous message (by thread): python logging filter limitation, looks intentional?
- Next message (by thread): python logging filter limitation, looks intentional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list