Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Wed, Dec 8, 2010 at 11:51 AM, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
>> Indeed - I was very surprised to find just now that calling
>> "logging.warn('Whatever')" is not the same as doing "log =
>> logging.getLogger(); log.warn('Whatever')".
>
> Don't know why you'd be surprised: it's been that way since logging was added
> to
> Python, and the logging.debug() etc. are documented as convenience methods for
> casual use in throwaway scripts, interactive sessions etc. The convenience is
> in
> that you don't need to specify a logger (the root logger is used) and that
> basicConfig() is called for you.
I've previously only used logging as an application author, hence I
hadn't noticed some of the subtleties that come up when using logging
in library code where you don't control which handlers are going to be
installed at runtime.
The surprise came from not realising there was a basicConfig() call
hidden inside the convenience APIs, a fact which is *not* mentioned in
the docstrings. It may be mentioned in the main documentation, but I
didn't look at that at the time - there was nothing to suggest the
docstrings were lacking pertinent information:
>>> print(logging.warn.__doc__)
Log a message with severity 'WARNING' on the root logger.
>>> print(logging.getLogger().warn.__doc__)
Log 'msg % args' with severity 'WARNING'.
To pass exception information, use the keyword argument exc_info with
a true value, e.g.
logger.warning("Houston, we have a %s", "bit of a problem", exc_info=1)
>> So my suggestion would be:
>> 1. In the absence of a "config" call, make the "no handler" path in
>> loggers emit messages *as if* basicConfig() has been called (without
>> actually calling it)
>> 2. Remove the implicit calls to basicConfig() from the module level
>> convenience function
>>
>> How *feasible* that idea is to implement, I don't know.
>>
>
> What about "Special cases aren't special enough to break the rules."? Why
> should
> logging from stdlib modules be treated differently from the case of logging
> from
> library modules in general? It could be argued that the behaviour you're
> proposing is confusing/inconsistent to some people.
I'm not proposing that the standard library be special-cased, I'm
proposing that the default behaviour of an unconfigured logging module
in general be changed to something more useful (i.e. warnings and
errors printed to stderr, everything else suppressed), rather than
unhelpfully suppressing *all* output except for an "Oh, I'm throwing
output away" message the first time it happens.
The specific use case that triggered my interest in this default
behaviour is one where concurrent.futures *can't* raise an exception
because it knows nothing is going to be in a position to handle that
exception (due to the way callbacks are handled, c.f knows it provides
the outermost exception handler in the affected call stack). Instead
it has to catch the error and display it *somewhere* (i.e. it's very
similar to the use cases for PyErr_WriteUnraisable at the C level).
The options for handling this are:
1. Write the error detail directly to stderr. (Unless the default
behaviour of logging changes, that is what I am going to suggest Brian
do, as it exactly mimics the behaviour of the PyErr_WriteUnraisable
API).
2. Write it to the root logger with the convenience APIs (Possible
option, but I don't like the global state impact of implicitly calling
basicConfig() from library code)
3. Add a StdErr handler for the logger (this is what is currently
implemented, and again, I don't like it because of the global state
impact on something that should be completely under an application's
control)
Basically, the current behaviour of logging is such that libraries
*cannot* use it for unraisable warnings and error messages, as the
messages will be suppressed unless the application takes steps to see
them. That is OK for debug and info messages, but unacceptable for
warnings and errors. A throwaway script using concurrent.futures needs
to know if callbacks are failing, and that needs to happen without any
logging related boilerplate in the script itself.
If, however, an application completely lacking even a call to
logging.basicConfig() would still see warnings and errors, then
libraries could safely use the module without needing to worry about
applications needing an particular boilerplate in order to see the
unraisable errors and warnings that are emitted.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] kill_python on windows buildbots
On 2010/12/08 0:11, David Bolen wrote: In thinking about it some more, I suppose there's still a small window for a loss of communication during a test which results in clean not being run (which could then block the next svn checkout without an opportunity to kill the processes), so maybe the right place is actually at the end of the test batch file which is the step during which such hung processes might get generated? I don't know the history, if any, of it's current location in the flow. Yes, but test can freeze. In that case, I'm worried that (snip) rt.bat # freeze here (will be halt by buildbot) vcbuild & kill_python_d # Will this be called? in test.bat. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 2010-12-07 17:58 , Vinay Sajip wrote: Robert Kern gmail.com> writes: If I had my druthers, I would simply remove the "No handlers could be found for logger XXX" message. If we always wrote entire applications from the ground up, it makes a lot of sense. The person that writes the code that issues logs is the same person that writes the code to configure logging for reading. If you add logging in one place, you almost certainly want to use it somewhere else and not setting up logging is probably an error. But when you want to write reusable libraries, those roles become separated. Exactly - we do use third-party libraries. When logging was added there was some debate about whether this one-off message should be printed, and in balance it was thought better to print this, not least because people would be unfamiliar with logging (as it was then new) and so be not unlikely to misconfigure it. No indication of this at all would be double-plus-ungood. I really don't understand how this view can be consistent with the practice of adding NullHandler to loggers. If this message is so important to prevent misconfiguration, then why should a library author decide to silence it for his users? I think that the chances of a misconfiguration that the warning would catch. are small in practice. I don't have any solid survey data on how people configure their loggers, but I strongly suspect that almost all configurations include a catch-all root logger and that most of those *only* consist of that root logger. As a library author, I would dearly love to just add logging liberally without placing any additional burden to the users of my library. If my users wants to read those logs, he will configure logging. If he doesn't, he won't. With the current behavior, I can't do that. If I add logging, he has to add code just to silence a message that is meaningless to him (after I get the support emails asking if things are broken and explain how to silence it). If I add a NullHandler, I remove the ability for him to use logging.basicConfig(), the easiest and most straightforward way for him to add logging to his application. You don't remove the ability for him to use basicConfig() - that's another mistake in your post (you already corrected the other mistake in your self-response). See my example with mylib.py/myapp.py in another post on this thread, in response to Antoine. Same mistake. I intended the correction to apply to all such statements in my post. This is only my personal anecdotal experience, but the current behavior has always wasted my time and never saved any of my time. That's because I think you're doing it wrong, or else I've misunderstood your use case. I will try to state it more plainly: the message has always been a false positive in my experience. It has never helped me fix a real problem and has otherwise wasted my time. NullHandler is the way to go, and doesn't preclude the use of basicConfig() UNLESS you choose to add the NullHandler to the root logger (not what you're supposed to do - you're supposed to add it to the top-level logger *of your library*, not the top-level logger of the logging hierarchy.) See the mylib/myapp example and tell me which it is - your mistake or mine? I think that boilerplate should be minimized. If using getLogger() should almost always be followed by adding a NullHandler, then it should be the default behavior. The easiest way to achieve this effect is to simply not issue the warning message. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Nick Coghlan gmail.com> writes:
> Indeed - I was very surprised to find just now that calling
> "logging.warn('Whatever')" is not the same as doing "log =
> logging.getLogger(); log.warn('Whatever')".
Don't know why you'd be surprised: it's been that way since logging was added to
Python, and the logging.debug() etc. are documented as convenience methods for
casual use in throwaway scripts, interactive sessions etc. The convenience is in
that you don't need to specify a logger (the root logger is used) and that
basicConfig() is called for you.
> Adding a NullHandler isn't the right thing to do - the behaviour I
> would want for any standard library logging that hasn't been
> explicitly configured otherwise is to do what the root logger does
> under basicConfig(): debug() and info() get suppressed, warn(),
> error(), critical() and exception() go to stderr. It seems to me like
> that would be more useful default behaviour in general than emitting a
> warning about not finding a handler.
>
> So my suggestion would be:
> 1. In the absence of a "config" call, make the "no handler" path in
> loggers emit messages *as if* basicConfig() has been called (without
> actually calling it)
> 2. Remove the implicit calls to basicConfig() from the module level
> convenience function
>
> How *feasible* that idea is to implement, I don't know.
>
What about "Special cases aren't special enough to break the rules."? Why should
logging from stdlib modules be treated differently from the case of logging from
library modules in general? It could be argued that the behaviour you're
proposing is confusing/inconsistent to some people.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Dec 08, 2010, at 12:01 AM, Vinay Sajip wrote: >Barry, if you mean +1 as in "I agree this is how it should work", then >we're all agreed. Yep, that's what I meant! -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Antoine Pitrou pitrou.net> writes: > > Why wouldn't it be the default for all logging calls ? Such special > cases don't really make things easy to remember. > One size doesn't fit all. Everything's documented reasonably well. If you use it often, you remember it. If you use it seldom, you might need to look things up. > You seem pretty tied up to the "application developer" situation. There > are cases (scripts, prototyping, etc.) where you certainly want to see > error messages (errors should not pass silently) but don't want to > configure logging for each of the libraries you use. You don't have to configure each of the libraries you use. The "application developer" = "The developer who is not writing a library" = "The person writing a script, prototyping, etc." I don't mean Application with a capital A. I'm just using it as a convenient label to mean a library user who is not writing a library themselves. > Having convenient and understandable defaults would go a long way > towards making logging more usable, IMO. > The defaults are I believe reasonably convenient, or at least not inconvenient: 1. If writing a library, add a NullHandler to the top-level logger of your library, don't add any other handlers by default (i.e. on import), document the names of the loggers you use. Otherwise, see the following. 2. If writing a simple script, prototyping etc. i.e. for casual use, use logging.debug(), logging.info() etc. That's easy enough and convenient enough for casual users to remember, I hope. All WARNING, ERROR and CRITICAL events in your code and in that of any libraries you use will be printed to sys.stderr. 3. If slightly less than very casual use (e.g. you want to log to file, or want a specific message format), call basicConfig(). Just the one extra line to remember to do, hopefully not too inconvenient. All WARNING, ERROR and CRITICAL events in your code and in that of any libraries you use will be printed to sys.stderr, unless you specify a file to log to and/or a different logging level, in which case what you specified will be used as destination/threshold for logging messages. 4. For more advanced use, use programmatic configuration, fileConfig or dictConfig to specify a configuration. Convenience is inversely proportional to how involved the configuration is. If you can specify what you think is inconvenient in the above, that would be helpful. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Wed, Dec 8, 2010 at 10:09 AM, Antoine Pitrou wrote:
> On Tue, 7 Dec 2010 23:45:39 + (UTC)
> Vinay Sajip wrote:
>> Antoine Pitrou pitrou.net> writes:
>>
>> >
>> > I thought "error" and "critical" messages were logged to stderr by
>> > default? Isn't it the case?
>> >
>>
>> Only if you call basicConfig() or use the logging.debug(), logging.info(),
>> etc.
>> module-level convenience functions (which call basicConfig under the hood).
>
> Why wouldn't it be the default for all logging calls ? Such special
> cases don't really make things easy to remember.
Indeed - I was very surprised to find just now that calling
"logging.warn('Whatever')" is not the same as doing "log =
logging.getLogger(); log.warn('Whatever')".
Adding a NullHandler isn't the right thing to do - the behaviour I
would want for any standard library logging that hasn't been
explicitly configured otherwise is to do what the root logger does
under basicConfig(): debug() and info() get suppressed, warn(),
error(), critical() and exception() go to stderr. It seems to me like
that would be more useful default behaviour in general than emitting a
warning about not finding a handler.
So my suggestion would be:
1. In the absence of a "config" call, make the "no handler" path in
loggers emit messages *as if* basicConfig() has been called (without
actually calling it)
2. Remove the implicit calls to basicConfig() from the module level
convenience function
How *feasible* that idea is to implement, I don't know.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/07/2010 07:09 PM, Vinay Sajip wrote: Eric Smith trueblade.com> writes: Wouldn't it make more sense to add these to test.support? I don't think we make any guarantees about its API being stable, although I have a faint recollection of that being debated in the past. That's what I mean when I said "unit test infrastructure" - adding to test.support. Sorry, I should have been more explicit. My bad. I read it as "unittest infrastructure". Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PyPI down?
The monitor said it went away at 23:50 UTC and came back 22 minutes later at 00:12 UTC. Richard On Wed, Dec 8, 2010 at 11:07 AM, MRAB wrote: > I can't get http://pypi.python.org and I've double-checked using > http://downforeveryoneorjustme.com/. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/richard%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Eric Smith trueblade.com> writes: > Wouldn't it make more sense to add these to test.support? I don't think > we make any guarantees about its API being stable, although I have a > faint recollection of that being debated in the past. > That's what I mean when I said "unit test infrastructure" - adding to test.support. Sorry, I should have been more explicit. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Tue, 7 Dec 2010 23:45:39 + (UTC) Vinay Sajip wrote: > Antoine Pitrou pitrou.net> writes: > > > > > I thought "error" and "critical" messages were logged to stderr by > > default? Isn't it the case? > > > > Only if you call basicConfig() or use the logging.debug(), logging.info(), > etc. > module-level convenience functions (which call basicConfig under the hood). Why wouldn't it be the default for all logging calls ? Such special cases don't really make things easy to remember. > When is the NullHandler needed? Only for cases where an application developer > uses a library which does logging under the covers (for those users who might > be > interested in logging its operations), but where that application developer > doesn't use logging themselves for that application. You seem pretty tied up to the "application developer" situation. There are cases (scripts, prototyping, etc.) where you certainly want to see error messages (errors should not pass silently) but don't want to configure logging for each of the libraries you use. Having convenient and understandable defaults would go a long way towards making logging more usable, IMO. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is PyPI down?
I can't get http://pypi.python.org and I've double-checked using http://downforeveryoneorjustme.com/. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Barry Warsaw python.org> writes: > > On Dec 07, 2010, at 04:59 PM, Robert Kern wrote: > > >As a library author, I would dearly love to just add logging liberally > >without placing any additional burden to the users of my library. If my users > >wants to read those logs, he will configure logging. If he doesn't, he > >won't. With the current behavior, I can't do that. If I add logging, he has > >to add code just to silence a message that is meaningless to him (after I get > >the support emails asking if things are broken and explain how to silence > >it). If I add a NullHandler, I remove the ability for him to use > >logging.basicConfig(), the easiest and most straightforward way for him to > >add logging to his application. > > +1 > Barry, if you mean +1 as in "I agree this is how it should work", then we're all agreed. But I think Robert is wrong that NullHandler precludes use of basicConfig - when NullHandler is added to a library logger (rather than the root logger), basicConfig() works as expected. See the mylib/myapp example in my other post on this thread. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Robert Kern gmail.com> writes: > If I had my druthers, I would simply remove the "No handlers could be > found for logger XXX" message. If we always wrote entire applications > from the ground up, it makes a lot of sense. The person that writes the > code that issues logs is the same person that writes the code to configure > logging for reading. If you add logging in one place, you almost certainly > want to use it somewhere else and not setting up logging is probably an > error. But when you want to write reusable libraries, those roles become > separated. Exactly - we do use third-party libraries. When logging was added there was some debate about whether this one-off message should be printed, and in balance it was thought better to print this, not least because people would be unfamiliar with logging (as it was then new) and so be not unlikely to misconfigure it. No indication of this at all would be double-plus-ungood. > As a library author, I would dearly love to just add logging liberally > without placing any additional burden to the users of my library. > If my users wants to read those logs, he will configure logging. If he > doesn't, he won't. With the current behavior, I can't do that. If I add > logging, he has to add code just to silence a message that is meaningless > to him (after I get the support emails asking if things are broken and > explain how to silence it). If I add a NullHandler, I remove the ability > for him to use logging.basicConfig(), the easiest and most straightforward > way for him to add logging to his application. You don't remove the ability for him to use basicConfig() - that's another mistake in your post (you already corrected the other mistake in your self-response). See my example with mylib.py/myapp.py in another post on this thread, in response to Antoine. > This is only my personal anecdotal experience, but the current behavior has > always wasted my time and never saved any of my time. > That's because I think you're doing it wrong, or else I've misunderstood your use case. NullHandler is the way to go, and doesn't preclude the use of basicConfig() UNLESS you choose to add the NullHandler to the root logger (not what you're supposed to do - you're supposed to add it to the top-level logger *of your library*, not the top-level logger of the logging hierarchy.) See the mylib/myapp example and tell me which it is - your mistake or mine? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Antoine Pitrou pitrou.net> writes:
>
> I thought "error" and "critical" messages were logged to stderr by
> default? Isn't it the case?
>
Only if you call basicConfig() or use the logging.debug(), logging.info(), etc.
module-level convenience functions (which call basicConfig under the hood).
> If any library defining a logger must also add a NullHandler just in
> case, ISTM that complicates a lot the use of logging (and could explain
> its impopularity). Both for library writers and application writers,
> apparently (since the former will have to add the NullHandler, and the
> latter will have to override it so that error messages get printed out
> rather than lost).
>
No - the application developer doesn't have to do anything special. Adding the
NullHandler is only needed for the top-level logger of a library package, so
it's hardly more onerous than doing an import. It doesn't complicate anything,
as far as I can see. It's to be done once per library, and trivial in comparison
with all the work needed to develop, test, and package a library. For the
stdlib, for example, if we were to standardize and say that all stdlib loggers
were to be located below the "py" namespace, then I could put the relevant
NullHandler-adding code in the logging package and no other stdlib maintainer
would have to do anything other than name their stdlib loggers beginning with
"py." (e.g. "py.concurrent.futures") for things to work as expected. If you
don't like "py", then pick "std", "stdlib" or whatever.
When is the NullHandler needed? Only for cases where an application developer
uses a library which does logging under the covers (for those users who might be
interested in logging its operations), but where that application developer
doesn't use logging themselves for that application. In such a case, a library
call which generated a logging event would cause logging to look for handlers,
and if one is not found, print that one-off "no handlers could be found for
logger XXX" message. This message is there because errors should not pass
silently; but in the case of an application developer oblivious of logging who
uses a library which uses logging under the hood, you can't argue that that
developer has made any error. So the library developer, by adding a NullHandler,
can improve things for their users by not forcing them to configure logging
handlers (in order to avoid the message).
#mylib.py
import logging
logger = logging.getLogger(__name__)
logger.addHandler(logging.NullHandler())
def func():
logger.warning('Something happened!')
#myapp.py
import mylib
mylib.func()
If you run myapp.py, no message is printed. If you comment out the "addHandler"
line and re-run, then you see
No handlers could be found for logger "mylib"
which is the misconfiguration message. With the line commented back in, you as
an application developer get expected behaviour (no spurious messages about
missing handlers). When you decide to use logging in myapp.py, simply insert
import logging
logging.basicConfig()
before calling mylib.func(), and you get
WARNING:mylib:Something happened!
which is what you would expect.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Dec 07, 2010, at 04:59 PM, Robert Kern wrote: >As a library author, I would dearly love to just add logging liberally >without placing any additional burden to the users of my library. If my users >wants to read those logs, he will configure logging. If he doesn't, he >won't. With the current behavior, I can't do that. If I add logging, he has >to add code just to silence a message that is meaningless to him (after I get >the support emails asking if things are broken and explain how to silence >it). If I add a NullHandler, I remove the ability for him to use >logging.basicConfig(), the easiest and most straightforward way for him to >add logging to his application. +1 -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/7/10 4:59 PM, Robert Kern wrote: On 12/7/10 2:26 PM, Vinay Sajip wrote: This issue was brought to my notice today: http://bugs.python.org/issue10626 and reference was made in the comments to possible obstacles facing stdlib maintainers who might wish to use logging in the stdlib and in its unit tests. From my perspective and as mentioned in the logging documentation, library code which uses logging should add a NullHandler instance to any top-level logger, which will avoid any "No handlers could be found for logger XXX" message if no logging handlers have been set up. I've done that before in my own library code, then quickly realized that it was a bad idea. Adding a NullHandler silently prevents logging.basicConfig() from working. Only on the root handler. Forget this bit of my argument (and the statements that directly follow from it). The rest of my argument should stand on its own, though. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Tue, Dec 7, 2010 at 13:57, Eric Smith wrote: > On 12/07/2010 03:26 PM, Vinay Sajip wrote: >> >> I would suggest that when unit testing, rather than adding StreamHandlers >> to log >> to stderr, that something like TestHandler and Matcher from this post: >> >> http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html >> >> This will allow assertion checking of logged messages without resorting to >> StringIO, getvalue() etc. If people think it's a good idea, I can add the >> TestHandler/Matcher classes to the unit test infrastructure (they wouldn't >> become part of the public API, at least until 3.3, but I presume they >> could be >> used in the stdlib unit tests). > > Wouldn't it make more sense to add these to test.support? I don't think we > make any guarantees about its API being stable, although I have a faint > recollection of that being debated in the past. We make no guarantees. The debate was whether we accidentally painted ourselves into a corner by documenting the module a tad for core developer's benefit. The warning has been made much more explicit in the docs that test.support is not meant for outside usage. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/7/10 2:26 PM, Vinay Sajip wrote: This issue was brought to my notice today: http://bugs.python.org/issue10626 and reference was made in the comments to possible obstacles facing stdlib maintainers who might wish to use logging in the stdlib and in its unit tests. From my perspective and as mentioned in the logging documentation, library code which uses logging should add a NullHandler instance to any top-level logger, which will avoid any "No handlers could be found for logger XXX" message if no logging handlers have been set up. I've done that before in my own library code, then quickly realized that it was a bad idea. Adding a NullHandler silently prevents logging.basicConfig() from working. Embedding that kind of restriction into library code (usually by a mere import!) made users unhappy and added an additional burden on the library developers who had to make sure to do that everywhere they used logging. If I had my druthers, I would simply remove the "No handlers could be found for logger XXX" message. If we always wrote entire applications from the ground up, it makes a lot of sense. The person that writes the code that issues logs is the same person that writes the code to configure logging for reading. If you add logging in one place, you almost certainly want to use it somewhere else and not setting up logging is probably an error. But when you want to write reusable libraries, those roles become separated. As a library author, I would dearly love to just add logging liberally without placing any additional burden to the users of my library. If my users wants to read those logs, he will configure logging. If he doesn't, he won't. With the current behavior, I can't do that. If I add logging, he has to add code just to silence a message that is meaningless to him (after I get the support emails asking if things are broken and explain how to silence it). If I add a NullHandler, I remove the ability for him to use logging.basicConfig(), the easiest and most straightforward way for him to add logging to his application. This is only my personal anecdotal experience, but the current behavior has always wasted my time and never saved any of my time. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Wiadomość napisana przez Antoine Pitrou w dniu 2010-12-07, o godz. 22:19:
>> If you're writing an application then the "No handlers could be found"
>> message is actually useful because there's hardly any reason no to include
>> one.
>
> Why do you say that? Not having to add a handler is certainly useful
> when you are doing some quick prototyping or simply writing a script
> (situations in which you still want to get error messages displayed
> properly by the libraries).
>
>> One way or the other, we should really default to the convenience of
>> application developers. This is currently the case.
>
> Why wouldn't there be a default convenience of printing out errors?
> It's already the case for the root handler, so why would other handler
> be treated differently?
>
import logging
logging.debug("foo")
logging.error("bar")
> ERROR:root:bar
If you're arguing that instead of writing "No handler", our logging library
could just as easily default to a simplistic stderr handler for errors, then I
agree. Both the convenience and consistency arguments you provided are
convincing. See, that was 3 times a con* in one sentence!
Then again, warning an application developer that some handler is not
configured that probably should be, is still valuable IMHO. Unless explicitly
silenced.
--
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
___
Python-Dev mailing list
Python-Dev@python.org
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 and the Unicode Character Database
2010/12/7 Alexander Belopolsky : > On Tue, Dec 7, 2010 at 8:02 AM, Vlastimil Brom > wrote: > .. >> Do you know of any re engine fully complying to to tr18, even at the >> first level: "Basic Unicode Support"? >> > """ > ICU Regular Expressions conform to Unicode Technical Standard #18 , > Unicode Regular Expressions, level 1, and in addition include Default > Word boundaries and Name Properties from level 2. > """ http://userguide.icu-project.org/strings/regexp > Thanks for the pointer, I wasn't aware of that project. Anyway I am quite happy with the mentioned regex library and can live with trading this full compliance for some non-unicode goodies (like unbounded lookbehinds etc.), but I see, it's beyond the point here. Not that my opinion matters, but I can't think of, say, "union, intersection and set-difference of Unicode sets" as a basic feature or consider it a part of "a minimal level for useful Unicode support." vbr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 12/07/2010 03:26 PM, Vinay Sajip wrote: I would suggest that when unit testing, rather than adding StreamHandlers to log to stderr, that something like TestHandler and Matcher from this post: http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html This will allow assertion checking of logged messages without resorting to StringIO, getvalue() etc. If people think it's a good idea, I can add the TestHandler/Matcher classes to the unit test infrastructure (they wouldn't become part of the public API, at least until 3.3, but I presume they could be used in the stdlib unit tests). Wouldn't it make more sense to add these to test.support? I don't think we make any guarantees about its API being stable, although I have a faint recollection of that being debated in the past. Eric. ___ Python-Dev mailing list Python-Dev@python.org 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 and the Unicode Character Database
On Tue, Dec 7, 2010 at 8:02 AM, Vlastimil Brom wrote: .. > Do you know of any re engine fully complying to to tr18, even at the > first level: "Basic Unicode Support"? > """ ICU Regular Expressions conform to Unicode Technical Standard #18 , Unicode Regular Expressions, level 1, and in addition include Default Word boundaries and Name Properties from level 2. """ http://userguide.icu-project.org/strings/regexp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Tue, 7 Dec 2010 22:04:36 +0100
Łukasz Langa wrote:
> Wiadomość napisana przez Antoine Pitrou w dniu 2010-12-07, o godz. 21:50:
>
> > If any library defining a logger must also add a NullHandler just in
> > case, ISTM that complicates a lot the use of logging (and could explain
> > its impopularity). Both for library writers and application writers,
> > apparently (since the former will have to add the NullHandler, and the
> > latter will have to override it so that error messages get printed out
> > rather than lost).
>
> ISTM that the stdlib is a special case here. If you're writing an application
> then the "No handlers could be found" message is actually useful because
> there's hardly any reason no to include one.
Why do you say that? Not having to add a handler is certainly useful
when you are doing some quick prototyping or simply writing a script
(situations in which you still want to get error messages displayed
properly by the libraries).
> One way or the other, we should really default to the convenience of
> application developers. This is currently the case.
Why wouldn't there be a default convenience of printing out errors?
It's already the case for the root handler, so why would other handler
be treated differently?
>>> import logging
>>> logging.debug("foo")
>>> logging.error("bar")
ERROR:root:bar
Thanks
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
Wiadomość napisana przez Antoine Pitrou w dniu 2010-12-07, o godz. 21:50: > If any library defining a logger must also add a NullHandler just in > case, ISTM that complicates a lot the use of logging (and could explain > its impopularity). Both for library writers and application writers, > apparently (since the former will have to add the NullHandler, and the > latter will have to override it so that error messages get printed out > rather than lost). ISTM that the stdlib is a special case here. If you're writing an application then the "No handlers could be found" message is actually useful because there's hardly any reason no to include one. If you're writing a library, well, that depends. Part of libraries might want to have their specific default handlers, part of them might want to leave that to the library user (e.g. "No handlers can be found" by default) and part of them might want to silence logs by default. One way or the other, we should really default to the convenience of application developers. This is currently the case. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On Tue, 7 Dec 2010 20:26:06 + (UTC) Vinay Sajip wrote: > > >From my perspective and as mentioned in the logging documentation, library > >code > which uses logging should add a NullHandler instance to any top-level logger, > which will avoid any "No handlers could be found for logger XXX" message if no > logging handlers have been set up. This applies to stdlib code, too, though it > would be good if a logger namespace could be agreed for stdlib usage. (The > logging package itself uses the logger "py.warnings" to redirect warnings to > logging when configured to do so. Perhaps we could standardize on "py.XXX" for > stdlib usage?) I thought "error" and "critical" messages were logged to stderr by default? Isn't it the case? If any library defining a logger must also add a NullHandler just in case, ISTM that complicates a lot the use of logging (and could explain its impopularity). Both for library writers and application writers, apparently (since the former will have to add the NullHandler, and the latter will have to override it so that error messages get printed out rather than lost). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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] r87118 - in python/branches/py3k: Mac/BuildScript/build-installer.py Makefile.pre.in
In article <4cfe6dd1.9030...@netwok.org>,
Éric Araujo wrote:
> > Author: ronald.oussoren
> > New Revision: 87118
> > Log: Two small changes to adjust framework builds to the new stable ABI
> >
> > Modified: python/branches/py3k/Mac/BuildScript/build-installer.py
> >
> > ==
> > +LDVERSION=None
> > +VERSION=None
> > +ABIFLAGS=None
> > +
> > +with open(os.path.join(buildDir, 'Makefile')) as fp:
> > +for ln in fp:
> > +if ln.startswith('VERSION='):
> > +VERSION=ln.split()[1]
> > +if ln.startswith('ABIFLAGS='):
> > +ABIFLAGS=ln.split()[1]
> > +
> > +if ln.startswith('LDVERSION='):
> > +LDVERSION=ln.split()[1]
> > +
> > +LDVERSION = LDVERSION.replace('$(VERSION)', VERSION)
> > +LDVERSION = LDVERSION.replace('$(ABIFLAGS)', ABIFLAGS)
>
> Isn’t this a perfect use case for the new sysconfig module?
There is no guarantee which version of Python the build-installer script
is being run with and, hence, no guarantee which version of sysconfig is
available. Typically it is an older system-supplied Python which is
fine as it is merely used to run build-installer (which includes running
Sphinx to build the documentation) and otherwise has no impact on the
Python being built.
--
Ned Deily,
n...@acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using logging in the stdlib and its unit tests
This issue was brought to my notice today: http://bugs.python.org/issue10626 and reference was made in the comments to possible obstacles facing stdlib maintainers who might wish to use logging in the stdlib and in its unit tests. >From my perspective and as mentioned in the logging documentation, library code which uses logging should add a NullHandler instance to any top-level logger, which will avoid any "No handlers could be found for logger XXX" message if no logging handlers have been set up. This applies to stdlib code, too, though it would be good if a logger namespace could be agreed for stdlib usage. (The logging package itself uses the logger "py.warnings" to redirect warnings to logging when configured to do so. Perhaps we could standardize on "py.XXX" for stdlib usage?) I would suggest that when unit testing, rather than adding StreamHandlers to log to stderr, that something like TestHandler and Matcher from this post: http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html This will allow assertion checking of logged messages without resorting to StringIO, getvalue() etc. If people think it's a good idea, I can add the TestHandler/Matcher classes to the unit test infrastructure (they wouldn't become part of the public API, at least until 3.3, but I presume they could be used in the stdlib unit tests). On the question of using logging in the stdlib and its unit tests, I would like to throw this open to python-dev: is there anyone here who wants to use logging but feels that they can't because of some shortcoming in logging? AFAIK there should be no obstacles. The preferred approach in stdlib code is as I have outlined above: add a NullHandler to top-level loggers to avoid misconfiguration, document the logger names you use, and avoid adding any other handlers by default. For unit testing, add a TestHandler (or equivalent) to your top-level logger at the start of the test, make any assertions you need to regarding what has been logged, remove the handler and close it at the end of the test. I don't believe there is any inherent conflict or incompatibility between logger usage in the stdlib, use of logging assertions in unit tests and use of handlers by application code, but I am happy to have any mistake on my part pointed out. >From what I've seen, concurrent.futures adds a StreamHandler which is removed >in the unit test and replaced by StreamHandler pointing to a different stream. This, I believe, should be changed in line with what I've said above. Comments? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org 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 and the Unicode Character Database
Am 07.12.2010 04:03, schrieb Alexander Belopolsky: > On Sat, Dec 4, 2010 at 5:58 PM, "Martin v. Löwis" wrote: >>> I actually wonder if Python's re module can claim to provide even >>> Basic Unicode Support. >> >> Do you really wonder? Most definitely it does not. >> > > Were you more optimistic four years ago? > > http://bugs.python.org/issue1528154#msg54864 Not at all. I thought back then, and think now, that Python should, but doesn't, support TR#18. I don't view that lack as a severe problem, though, and apparently none of the other contributors did so, either. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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] r87118 - in python/branches/py3k: Mac/BuildScript/build-installer.py Makefile.pre.in
Hello,
> Author: ronald.oussoren
> New Revision: 87118
> Log: Two small changes to adjust framework builds to the new stable ABI
>
> Modified: python/branches/py3k/Mac/BuildScript/build-installer.py
> ==
> +LDVERSION=None
> +VERSION=None
> +ABIFLAGS=None
> +
> +with open(os.path.join(buildDir, 'Makefile')) as fp:
> +for ln in fp:
> +if ln.startswith('VERSION='):
> +VERSION=ln.split()[1]
> +if ln.startswith('ABIFLAGS='):
> +ABIFLAGS=ln.split()[1]
> +
> +if ln.startswith('LDVERSION='):
> +LDVERSION=ln.split()[1]
> +
> +LDVERSION = LDVERSION.replace('$(VERSION)', VERSION)
> +LDVERSION = LDVERSION.replace('$(ABIFLAGS)', ABIFLAGS)
Isn’t this a perfect use case for the new sysconfig module?
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 11: Dropping support for ten year old systems
On Tue, 2010-12-07 at 00:05 +0100, "Martin v. Löwis" wrote: > >> So by this policy, RHEL and SuSE users would be off worse than with > >> my original proposal (10 years). > > > > Red Hat continues to provide patches for RHEL within the "Extended Life > > Cycle" (years 8, 9 and 10), but it's an optional add-on. > > My understanding is that you keep the patches available - but you > don't produce any new ones, right? It typically involves backporting (and testing) security fixes to the older versions of the various OS packages. Whether or not the results of that work count as "new patches" is debatable. I don't know if CentOS and the other people who rebuild the RHEL sources track those final 3 years. Dave ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] kill_python on windows buildbots
Tres Seaver writes: > Maybe belt-and-suspenders it in both places. The clean batch file is also called from the build step, so relocating it there should maintain the existing behavior as well. Hirokazu (ocean-city) pointed out in my new issue an earlier issue he created (#9973) that included a patch for such a change. In thinking about it some more, I suppose there's still a small window for a loss of communication during a test which results in clean not being run (which could then block the next svn checkout without an opportunity to kill the processes), so maybe the right place is actually at the end of the test batch file which is the step during which such hung processes might get generated? I don't know the history, if any, of it's current location in the flow. Relocating the use of kill_python seems reasonable to me, after which we could sort of wait and see if we run into any other hangs that interfere with the builds. I can't make such a change myself though. -- David ___ Python-Dev mailing list Python-Dev@python.org 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 and the Unicode Character Database
On Tue, Dec 7, 2010 at 8:02 AM, Vlastimil Brom wrote: .. > It seems, e.g. in Perl, there are some omissions too > http://perldoc.perl.org/perlunicode.html#Unicode-Regular-Expression-Support-Level > > Do you know of any re engine fully complying to to tr18, even at the > first level: "Basic Unicode Support"? > I would say Perl comes very close. At least it explicitly documents the missing features and offers workarounds in its reference manual. I am actually not as concerned about missing features as I am about non-conformance in the widely used features such as digits' matching with '\d'. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] kill_python on windows buildbots (was Re: Stable buildbots)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/06/2010 07:24 PM, David Bolen wrote: > I previously wrote: > >> I suspect the problem may be on the "identify which process to kill" >> rather than the "kill it" part, but it's definitely going to take time >> to figure that out for sure. While the approach kill_python takes is >> much more appropriate, since we don't currently have multiple builds >> running simultaneously (and for me the machines are dedicated as build >> slaves, so I won't be having my own python_d), a more blanket kill >> operation is safe enough. > > For anyone interested, I caught (well, Georg Brandl caught it first) a > case on Saturday with some hung processes on the Win7 buildbot that I > was able to verify kill_python failed to kill. This was after having > a few instances where it did work fine. > > I've created issue 10641 to track. I also noticed another recent > issue (10136) that is also related to kill_python missing processes, > but given that it works in my case some of the time, and is always > called via the same path, not sure if that can be my problem. > > I also realized that some fraction of the other cases I have seen > might not have truly been an issue, since from what I can see > kill_python is only run at the start of a build process, so hung > processes (even killable ones) from a prior build hang around until > the next build takes place. They can however, interfere with the svn > checkout so things never get to the point of using kill_python. So > maybe kill_python's use should be moved to the clean stage? Maybe belt-and-suspenders it in both places. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+RuYACgkQ+gerLs4ltQ58OgCgiMs1JAdFjkOGxrJ3X3nB1k18 iKcAoMCP+MYumDe0r/XkZr29e7loACxP =wrWe -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org 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 and the Unicode Character Database
2010/12/7 Alexander Belopolsky : > On Sat, Dec 4, 2010 at 5:58 PM, "Martin v. Löwis" wrote: >>> I actually wonder if Python's re module can claim to provide even >>> Basic Unicode Support. >> >> Do you really wonder? Most definitely it does not. >> > > Were you more optimistic four years ago? > > http://bugs.python.org/issue1528154#msg54864 > > I was hoping that regex syntax would be useful in > explaining/documenting Python text processing routines (including > string to number conversions) without a heavy dose of Unicode > terminology. > The new regex version http://bugs.python.org/issue2636 supports much more features, including unicode properties, and the mentioned possix classes etc. but definitely not all of the requirements of that rather "generous" list. http://www.unicode.org/reports/tr18/ It seems, e.g. in Perl, there are some omissions too http://perldoc.perl.org/perlunicode.html#Unicode-Regular-Expression-Support-Level Do you know of any re engine fully complying to to tr18, even at the first level: "Basic Unicode Support"? vbr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 11: Dropping support for ten year old systems
On 6 December 2010 18:55, "Martin v. Löwis" wrote: > Am 06.12.2010 14:40, schrieb Floris Bruynooghe: >> On 6 December 2010 09:18, "Martin v. Löwis" wrote: Also, it is not clear what to do about distributions/OSs without any official EOL or life cycles. >>> >>> Here my proposal stands: 10 years, by default. >> >> How about max(EOL, 10years)? That sounds like it could be a useful >> guideline. >> >> (Personally I'd be sad to see Solaris 8 go in the next few years) > > I guess we'll be sorry, then: under that policy, max(EOL, 10years) comes > out as "not supported" (not sure whether you were aware of that). I was :-) Which is why I said "sad" and not "panic" or something. I do realise I'm probably in the minority and that it doesn't justify the burden on everyone in the Python community. > We are not going to take the sources of old releases offline. exactly Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.2 beta 1
Wiadomość napisana przez Georg Brandl w dniu 2010-12-06, o godz. 22:46: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On behalf of the Python development team, I'm happy to announce the > first of two beta preview releases of Python 3.2. > > Python 3.2 is a continuation of the efforts to improve and stabilize the > Python 3.x line. Since the final release of Python 2.7, the 2.x line > will only receive bugfixes, and new features are developed for 3.x only. > > Since PEP 3003, the Moratorium on Language Changes, is in effect, there > are no changes in Python's syntax and built-in types in Python 3.2. > Development efforts concentrated on the standard library and support for > porting code to Python 3. Highlights are: > > [snip] * configparser 1.1: new API using the mapping protocol access, support for pluggable interpolation handlers, additional interpolation handler (ExtendedInterpolation) which supports the zc.buildout syntax, support for alternative option/value delimiters, support for customization of accepted INI file structure (e.g. comment prefixes, name of the DEFAULT section, indentation, empty lines in multiline values, etc.), support for specifying encoding for read operations, ConfigParser class deprecated in favor of SafeConfigParser, lots of other small changes. -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
