Re: [Python-Dev] locale and LC_NUMERIC
On 1/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > I know very little about locale's. /f assigned me a bug > > http://python.org/sf/1391872 which suggests I run all the tests in a > > different locale than C. I think this is a good idea, but when I set > > LANG or LC_ALL or LC_CTYPE in the env't the locale isn't set without > > me calling locale.setlocale(). Shouldn't we maintain the value from > > the env't? > > I feel I'm lacking some link here: why do you think we should do that? [EMAIL PROTECTED] ~/build/python/svn/clean-ish $ LC_ALL=de_DE ./python >>> import locale >>> locale.setlocale(locale.LC_ALL) 'C' >>> locale.setlocale(locale.LC_ALL, 'de_DE') 'de_DE' I would have expected the first call to setlocale() to return de_DE. /f solution of adding a flag to the test runner should work for the bug report I mentioned. Part of the reason why I asked was because I'm confused by the current behaviour. Is the first call to setlocale() supposed to return C? If so, always? I was looking for some way for the initial call to setlocale() to return de_DE or whatever other locale I set. > What does "start with the correct locale" mean? What is the "correct > locale"? Python should work in any locale, Hopefully my explanation above answered all those questions. > and locale.format > should always give the locale-specific formatting, whereas "%f" % value > should always give the result from the "C" locale (regardless of > whether the application has called setlocale or not). Right. I'm working on a patch for this problem which is independent of what I was asking. I really should have started a new thread, but I wasn't completely sure when I asked if there was a relationship. Also, in Georg's snippet, he didn't show that he was setting the locale, only what it was set to. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
Neal Norwitz wrote: > > I feel I'm lacking some link here: why do you think we should do that? > > [EMAIL PROTECTED] ~/build/python/svn/clean-ish $ LC_ALL=de_DE ./python > >>> import locale > >>> locale.setlocale(locale.LC_ALL) > 'C' > >>> locale.setlocale(locale.LC_ALL, 'de_DE') > 'de_DE' > > I would have expected the first call to setlocale() to return de_DE. the locale is a program-specific setting (handled by the C runtime library), and is set to "C" by default. if you want to use a specific locale, you have to call setlocale to indicate that you really want a non-default locale. the "" argument is just a con- venience; it tells the C runtime library to set the locale based on OS-level language settings (e.g. LANG on Unix, control panel settings on Windows, etc). LANG in itself isn't the locale; it's just a way to tell a locale-aware program what the preferred locale is. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
On 1/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Georg Brandl wrote: > > >>> import locale > > >>> locale.setlocale(locale.LC_NUMERIC, "") > > '[EMAIL PROTECTED]' > > >>> u"%f" % 1.0 > > u'1,00' > > > > Is this intended? This breaks test_format on my box when test_builtin > > (method > > test_float_with_comma) is executed first. > > No. %-formatting should always use the C locale. One should use > locale.format to get locale-aware formatting. http://python.org/sf/1400181 fixes this problem I hope. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Georg Brandl <[EMAIL PROTECTED]> writes: > The call to curses.setupterm() leaves my terminal in a bad state. Hmm. > The reset program outputs: > Erase set to delete. > Kill set to control-U (^U). > Interrupt set to control-C (^C). It always says that :) (unless you've messed with stty, I guess) > Doesn't the setupterm() have to be paired with something like shutdownterm()? Not as far as my memory of curses goes. From the man page: The setupterm routine reads in the terminfo database, initializing the terminfo structures, but does not set up the output virtualization structures used by curses. What platform are you on? Cheers, mwh -- #ifndef P_tmpdir printf( "Go buy a better computer" ); exit( ETHESKYISFALLINGANDIWANTMYMAMA ); -- Dimitri Maziuk on writing secure code, asr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
Fredrik Lundh wrote: > my rationale for running the tests with a non-US locale was to increase > the chance of catching bugs where the external locale setting affects > Python's behaviour. > > maybe it would be a good idea to add a "use setlocale" flag to the test- > runner ? Sounds like a good use for buildbot. After running the tests "normally" they could be re-run with a different locale. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser to save with order
2006/1/7, Guido van Rossum <[EMAIL PROTECTED]>: > I think it's moot unless you also preserve comments. Ideally would be > something that prserved everything (ordering, blank lines, comments > etc.) from how it was read in. Modifying a value should keep its > position. Adding a value should add it to the end of the section it's > in (unless there are cases where ordering is important to the > semantics -- are there?). Not in my case. We can rewrite ConfigParser to store everything and write it back in the exact order it took it, with new values at the end of each section (or where the user inserted it), but it'll took a big rewrite of the module: right now it's using dictionaries and should use lists to achieve that behaviour. What I wanted to add to the module was predicatibility: a very needed feature when you're writing test cases (and that's where I got bite). .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser to save with order
On Monday 09 January 2006 12:08, Facundo Batista wrote: > What I wanted to add to the module was predicatibility: a very needed > feature when you're writing test cases (and that's where I got bite). In that case, would sorting the keys within each section be sufficient when writing it back out? I had a class to do the really-careful editing bit like Guido described once, but lost it in a disk crash several years ago. I really wish I'd gotten that into revision control somewhere, but it's too late now. I've not needed that badly enough to re-write it. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
...
[Tim]
>> That's no more or less painful than using C99's huge pile of PRId8,
>> PRId16, PRId32 (etc, etc) macros, defined there for similar purposes.
[Martin]
> Right - and I consider them just as painful.
>
> If you believe that this is really what we should be doing, then, well,
> let's do it.
I think it's clear that in a 64-bit world, we absolutely need a way to
format 64-bit integers. I'm dubious that Neil's specific line of code
needed Py_ssize_t to begin with, but increasing amounts of other code
will.
Maybe this wasn't clear: I think Neil's code _should_ be able to put
"%zd" in the format string, not using format macros at all. IOW, I
believe the supporting routines for PyErr_Format() and
PyString_Format() should be taught to recognize the C99-standard "z"
qualifier and implement its semantics in a platform-correct way.
That's where the irritating macros would be used, _inside_ the
implementations of Py{Err,String}_Format(). Code passing a Py_ssize_t
to one of those would just use "%zd" directly in its format string,
and on all platforms.
It's only code calling printf/fprintf/sprintf directly with a
Py_ssize_t or size_t output value that would need to use the format
macros, and I don't think there's a lot of that -- looks like most
relevant messages are constructed by Py{Err,String}_Format().
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
[Tim] >> We could use the "I" (capital letter eye) length modifier under VC7.1. >> That's good for both size_t and ptrdiff_t formats under VC7.1, where >> ptrdiff_t under VC7.1 is really the same concept as Py_ssize_t. [Martin] > ptrdiff_t has the advantage of being available on all platforms, > being part of C89 (IIRC). Should we use ptrdiff_t instead of > Py_ssize_t? Formally, ptrdiff_t could be different from size_t > (in width); reportedly, there are 8086 compilers which had > a 16-bit size_t (maximum size of a segment), but a 32-bit > ptrdiff_t (allowing for cross-segment differences, something > that apparently became undefined in C99). I grew up on 60- and 64-bit boxes, but all I've worked on for the last decade is 32-bit Pentium chips. If there's a Python platform where sizeof(size_t) != sizeof(ptrdiff_t), I don't know about it, but I'm not sure I have a reason to _expect_ to be aware of such things anymore. Regardless, I like Py_ssize_t: it clearly says "same width as size_t, but signed". "Difference between two pointers" is obscurely related to that at best. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
On 1/9/06, Tim Peters <[EMAIL PROTECTED]> wrote: > ... > > [Tim] > >> That's no more or less painful than using C99's huge pile of PRId8, > >> PRId16, PRId32 (etc, etc) macros, defined there for similar purposes. > > [Martin] > > Right - and I consider them just as painful. > > > > If you believe that this is really what we should be doing, then, well, > > let's do it. > > I think it's clear that in a 64-bit world, we absolutely need a way to > format 64-bit integers. I'm dubious that Neil's specific line of code > needed Py_ssize_t to begin with, but increasing amounts of other code > will. I wasn't always sure which choice to make. I generally tried to leave the warnings when I wasn't sure. Like you and Martin I agree this is a problem, though I don't have any good ideas how to fix. They all seem kinda painful. I often chose to use Py_ssize_t rather than int if it was capturing the result of a sequence length. But often this is larger than what will be allowed (like in this case). The problem then comes that we have cases everywhere if we leave things as ints. Stuff like this: len = (int) PyTuple_Size(co_consts); How do we know that is safe or not? Also, maybe it would be nice to have defined maximum sizes enforced by the compiler for lots of fields in code objects, etc. Like 32k for # local variables, parameters, free variables, etc. But when we add these together in the stack for extras, we would still need to use at least 32 bits. And there's still the possibility of overflow when we add these pieces together. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
Martin v. Löwis wrote: > Georg Brandl wrote: >> >>> import locale >> >>> locale.setlocale(locale.LC_NUMERIC, "") >> '[EMAIL PROTECTED]' >> >>> "%f" % 1.0 >> '1.00' >> >>> u"%f" % 1.0 >> u'1,00' >> >>> >> >> >> Is this intended? This breaks test_format on my box when test_builtin (method >> test_float_with_comma) is executed first. > > No. %-formatting should always use the C locale. One should use > locale.format to get locale-aware formatting. While we're at it: test_builtin does import locale orig_locale = locale.setlocale(locale.LC_NUMERIC, '') locale.setlocale(locale.LC_NUMERIC, 'fr_FR') and later finally: locale.setlocale(locale.LC_NUMERIC, orig_locale) Shouldn't the first setlocale have no second argument? regards, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_curses
Michael Hudson wrote: > Georg Brandl <[EMAIL PROTECTED]> writes: > >> The call to curses.setupterm() leaves my terminal in a bad state. > > Hmm. > >> The reset program outputs: >> Erase set to delete. >> Kill set to control-U (^U). >> Interrupt set to control-C (^C). > > It always says that :) (unless you've messed with stty, I guess) Well, when I do a reset without meddling with the terminal, it says nothing, at least on my box. And, there's more: Ctrl+D doesn't work, Ctrl+C doesn't work. I just looked, my .profile contains "stty sane cr0 pass8 dec". >> Doesn't the setupterm() have to be paired with something like shutdownterm()? > > Not as far as my memory of curses goes. From the man page: > >The setupterm routine reads in the terminfo database, >initializing the terminfo structures, but does not set up the >output virtualization structures used by curses. > > What platform are you on? Linux 2.6, ncurses 5.5, TERM=xterm. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Logging enhancements
I'd like to create a patch for the logging package, but before I do, I need to know whether someone else is working on the package and whether my patch is likely to be accepted. Is there another group I should talk to? Specifically, I want to change the following: - The logging.config.fileConfig function has bare excepts that hide configuration errors. I'd like to remove the bare excepts and break up fileConfig for clarity. - I'd like to make it possible to configure the format of exception tracebacks. Some logs want compressed tracebacks like Medusa; others want extra information like Zope. - There is no support for external log rotation. There is plenty of support for Python rotating logs directly, but permission settings often make that impossible. Long-running Python processes need to accept a signal which notifies them when an external tool rotates the logs. - The logging documentation is lacking somewhat. For example, it fails to mention that the logging handlers are in the 'handlers' module, which I only learned by searching the source code. Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
Neal Norwitz wrote: > [EMAIL PROTECTED] ~/build/python/svn/clean-ish $ LC_ALL=de_DE ./python > import locale locale.setlocale(locale.LC_ALL) > > 'C' > locale.setlocale(locale.LC_ALL, 'de_DE') > > 'de_DE' > > I would have expected the first call to setlocale() to return de_DE. No, it shouldn't. We are providing C semantics here, which is that no locale functionality is activated unless the application explicitly asks for it. > Is the first call to > setlocale() supposed to return C? If so, always? The return value is implementation-defined, but yes, it is supposed to return the "C" locale (which is synonymous to the "POSIX" locale on a POSIX system). > I was looking for > some way for the initial call to setlocale() to return de_DE or > whatever other locale I set. That shouldn't happen. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c
Neal Norwitz wrote: > I often chose to use Py_ssize_t rather than int if it was capturing > the result of a sequence length. But often this is larger than what > will be allowed (like in this case). The problem then comes that we > have cases everywhere if we leave things as ints. This is also the strategy I have been following. The alternative would be to add error handling at the places where truncation occurs (unless you can *really* determine statically that there never ever will be truncation). This is too painful, so it is IMO better to carry the wide values throughout, until the place where the range check is carried out. > Stuff like this: > len = (int) PyTuple_Size(co_consts); > > How do we know that is safe or not? Well, you know that LOAD_CONST only supports 2**31 constants, so truncation to int is currently safe (I hope that the compiler detects cases where somebody tries to create more than 2**16 constants). Still, this is only the *current* state. Going further, it might be that some of the restrictions are lifted someday, so we would have to review all casts then to see whether they are still safe. Therefore, I think having fewer casts is better. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
Georg Brandl wrote: > import locale > orig_locale = locale.setlocale(locale.LC_NUMERIC, '') > locale.setlocale(locale.LC_NUMERIC, 'fr_FR') > > and later > > finally: > locale.setlocale(locale.LC_NUMERIC, orig_locale) > > > Shouldn't the first setlocale have no second argument? Oops, right - it certainly should. Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > I'd like to create a patch for the logging package, but before I do, I > need to know whether someone else is working on the package and whether > my patch is likely to be accepted. Is there another group I should talk to? Vinay (copied) maintains it separately. He's the best person to talk to AFAIK. He maintains compatability with older pythons, possibly 1.5, I don't recall. Check PEP 291. > Specifically, I want to change the following: There are several bugs (any maybe patches) on SF related to logging. AFAIK, they are all assigned to Vinay. It would be great if you could fix those as well. n -- > - The logging.config.fileConfig function has bare excepts that hide > configuration errors. I'd like to remove the bare excepts and break up > fileConfig for clarity. > > - I'd like to make it possible to configure the format of exception > tracebacks. Some logs want compressed tracebacks like Medusa; others > want extra information like Zope. > > - There is no support for external log rotation. There is plenty of > support for Python rotating logs directly, but permission settings often > make that impossible. Long-running Python processes need to accept a > signal which notifies them when an external tool rotates the logs. > > - The logging documentation is lacking somewhat. For example, it fails > to mention that the logging handlers are in the 'handlers' module, which > I only learned by searching the source code. > > Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser to save with order
2006/1/9, Fred L. Drake, Jr. <[EMAIL PROTECTED]>: > On Monday 09 January 2006 12:08, Facundo Batista wrote: > > What I wanted to add to the module was predicatibility: a very needed > > feature when you're writing test cases (and that's where I got bite). > > In that case, would sorting the keys within each section be sufficient when > writing it back out? Yes, because giving a set of sections and values inside them, you know in advance how they'll finish in the file. > I had a class to do the really-careful editing bit like Guido described once, > but lost it in a disk crash several years ago. I really wish I'd gotten that > into revision control somewhere, but it's too late now. I've not needed that > badly enough to re-write it. Somebody (me, for example) can write it if we all decide that that's the desired behaviour. We just need to take a side. Me, I just need the predicatibility that sort() gives. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] locale and LC_NUMERIC
On 1/9/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > > I would have expected the first call to setlocale() to return de_DE. > > No, it shouldn't. We are providing C semantics here, which is that > no locale functionality is activated unless the application explicitly > asks for it. Thanks (to /f too). That was the part that I was missing. It makes sense now. I made the patch to do this. It's called before each class' test run in regrtest.py. I would prefer to set the locale before each test method run, but I need to muck with unittest for that IIRC. There were 2 failures. One was in test_email which needs the C locale for generating the proper timestamp. The other was (IIRC) in test_re, 2 methods failed. So we are hopefully in decent shape. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
Neal Norwitz wrote: > On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > >>I'd like to create a patch for the logging package, but before I do, I >>need to know whether someone else is working on the package and whether >>my patch is likely to be accepted. Is there another group I should talk to? > > > Vinay (copied) maintains it separately. He's the best person to talk > to AFAIK. He maintains compatability with older pythons, possibly > 1.5, I don't recall. Check PEP 291. > > >>Specifically, I want to change the following: > > > There are several bugs (any maybe patches) on SF related to logging. > AFAIK, they are all assigned to Vinay. It would be great if you could > fix those as well. What is the time frame for Python 2.5? If I finish soon and the changes are not disruptive, do I have enough time for my changes to make it into 2.5? Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
On Mon, Jan 09, 2006, Shane Hathaway wrote: > > What is the time frame for Python 2.5? If I finish soon and the changes > are not disruptive, do I have enough time for my changes to make it into > 2.5? There is still no official timeframe for 2.5. Alpha is hoped for March/April; final release for June/July. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
[Shane Hathaway] > What is the time frame for Python 2.5? If I finish soon and the changes > are not disruptive, do I have enough time for my changes to make it into > 2.5? Yup! 2.5 hasn't even had an alpha release yet, and I don't expect 2.5a1 before March: http://mail.python.org/pipermail/python-dev/2005-August/055342.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
Tim Peters wrote: > [Shane Hathaway] > >>What is the time frame for Python 2.5? If I finish soon and the changes >>are not disruptive, do I have enough time for my changes to make it into >>2.5? > > > Yup! 2.5 hasn't even had an alpha release yet, and I don't expect > 2.5a1 before March: > > http://mail.python.org/pipermail/python-dev/2005-August/055342.html That's good news. Thanks. Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
Hi Shane, On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > I'd like to create a patch for the logging package, but before I do, I > need to know whether someone else is working on the package and whether > my patch is likely to be accepted. Is there another group I should talk to? I maintain the logging package, and I will happily review patches and apply them where I think they're fine. I have accepted many patches to the package, some via SF and some sent privately, but also rejected a few. For example, the TimedRotatingFileHandler was submitted by someone. Patches need to be compatible with Python 1.5.2. > - The logging.config.fileConfig function has bare excepts that hide > configuration errors. I'd like to remove the bare excepts and break up > fileConfig for clarity. I've no problem with this in principle, though there have been cases where ConfigParser behaviour is not what you would expect (e.g. a non-existent file leads to a "missing section" exception). I'd be grateful for more specifics as to where you have encountered problems. > - I'd like to make it possible to configure the format of exception > tracebacks. Some logs want compressed tracebacks like Medusa; others > want extra information like Zope. Again, no problem in principle, but it's probably an unusual use case so any change should not require extra work for users without specialised requirements. > - There is no support for external log rotation. There is plenty of > support for Python rotating logs directly, but permission settings often > make that impossible. Long-running Python processes need to accept a > signal which notifies them when an external tool rotates the logs. I'd be interested in your approach to solve this. > - The logging documentation is lacking somewhat. For example, it fails > to mention that the logging handlers are in the 'handlers' module, which > I only learned by searching the source code. Not true for this specific case - for example, http://docs.python.org/lib/module-logging.html has a list of 12 handlers, followed by a statement to the effect that all but StreamHandler and FileHandler are defined in the handlers module. In general, patches are gratefully received! If you don't want to invest too much time up front, send me a mail indicating your general approach and we'll discuss. Best regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
Vinay Sajip wrote: > On 1/9/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: >>- The logging.config.fileConfig function has bare excepts that hide >>configuration errors. I'd like to remove the bare excepts and break up >>fileConfig for clarity. > > I've no problem with this in principle, though there have been cases where > ConfigParser behaviour is not what you would expect (e.g. a non-existent > file leads to a "missing section" exception). I'd be grateful for more > specifics as to where you have encountered problems. I wrote a config file with an invalid handler section. Because of the bare except, not only was my error not reported anywhere, but the daemon started with no logging at all. It took me a while to realize what had happened. The logging package needs to report erroneous configurations. >>- I'd like to make it possible to configure the format of exception >>tracebacks. Some logs want compressed tracebacks like Medusa; others >>want extra information like Zope. > > Again, no problem in principle, but it's probably an unusual use case so any > change should not require extra work for users without specialised > requirements. Agreed. >>- There is no support for external log rotation. There is plenty of >>support for Python rotating logs directly, but permission settings often >>make that impossible. Long-running Python processes need to accept a >>signal which notifies them when an external tool rotates the logs. > > I'd be interested in your approach to solve this. To be compatible with an external tool like logrotate, all a daemon needs to do is close and reopen log files at about the same time log rotation happens. To handle this use case, I suggest the logging module needs a function named reopen(), which daemons can call upon receipt of a signal. The reopen function will find all handlers with open files and ask them to reopen. >>- The logging documentation is lacking somewhat. For example, it fails >>to mention that the logging handlers are in the 'handlers' module, which >>I only learned by searching the source code. > > > Not true for this specific case - for example, > http://docs.python.org/lib/module-logging.html has a list of 12 handlers, > followed by a statement to the effect that all but StreamHandler and > FileHandler are defined in the handlers module. Oops. I guess I skipped over that because I was using the documentation as a reference rather than as a tutorial. I suggest the documentation needs to become a better reference. > In general, patches are gratefully received! If you don't want to invest too > much time up front, send me a mail indicating your general approach and > we'll discuss. I'll get started soon. I just wanted to be sure I'm not duplicating someone else's efforts. Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Logging enhancements
On Tue, 2006-01-10 at 00:01 +, Vinay Sajip wrote: > I maintain the logging package, and I will happily review patches and apply > them where I think they're fine. I have accepted many patches to the > package, some via SF and some sent privately, but also rejected a few. For > example, the TimedRotatingFileHandler was submitted by someone. > > Patches need to be compatible with Python 1.5.2. I've been thinking about this compatibility thing too, especially w.r.t. the email package. For example, I still want to maintain email 2.5 which has b/c to Python 2.1. But email 3.0 need only be compatible with Python 2.3. Given that we now have everything in Subversion, I think it makes it much easier to maintain multiple versions of separately distributed packages, modulo the time it takes to do so. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
