Re: [Python-Dev] nonlocal x = value
On Dec 25, 2010, at 2:59 AM, Stefan Behnel wrote: > Hrvoje Niksic, 24.12.2010 09:45: >> On 12/23/2010 10:03 PM, Laurens Van Houtven wrote: >>> On Thu, Dec 23, 2010 at 9:51 PM, Georg Brandl wrote: Yes and no -- there may not be an ambiguity to the parser, but still to the human. Except if you disallow the syntax in any case, requiring people to write nonlocal x = (3, y) which is then again inconsistent with ordinary assignment statements. >>> >>> Right -- but (and hence the confusion) I was arguing for not mixing >>> global/nonlocal with assignment at all, and instead having nonlocal >>> and global only take one or more names. That would (obviously) remove >>> any such ambiguity ;-) >> >> I would like to offer the opposing viewpoint: nonlocal x = value is a >> useful shortcut because nonlocal is used in closure callbacks where >> brevity matters. > > I doubt that it really matters so much that one line more kills readability. > It's still a relatively rare use case after all. > > >> The reason nonlocal is introduced is to change the >> variable, so it makes sense that the two can be done in the same line of >> code. FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition. * It is easily mis-parsed by human (as shown by Georg's examples). * It looks very much like an initialization of a local variable in many languages, but it is not -- the variable has already been initialized in another scope. * It is not clear how to extend it to multiple variables (which we already allow). * It is entirely unnecessary. Just add a real assignment on the following line: local x x = 3, y * We've had global declarations for a very long time and never needed (or wanted) an assignment for it: global x = 3, y * The purported use case is rare (at best). Special cases aren't worth breaking the rules. And the purported goal (saving one line) isn't much of a payoff. * The language moratorium is ending but the aversion to non-essential micro-syntax changes persists. * And, Georg doesn't like it :-) Raymond ___ 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] r87445 - python/branches/py3k/Lib/numbers.py
On Fri, Dec 24, 2010 at 1:08 AM, Nick Coghlan wrote: >> def __index__(self): >> - """index(self)""" >> + """someobject[self]""" >> return int(self) > > Changing the docstring to say "operator.index(self)" would be the > clearest solution here. Agreed. Certainly "someobject[self]" isn't right. (There's also a question about whether __index__ should really be defaulting to int, but that's another issue...) Mark ___ 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] nonlocal x = value
On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger wrote: > FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition. > [...] -1 for assignment in nonlocal and global statements from me, too. Mark ___ 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] nonlocal x = value
On Mon, Dec 27, 2010 at 8:31 PM, Mark Dickinson wrote: > On Mon, Dec 27, 2010 at 9:43 AM, Raymond Hettinger > wrote: >> FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition. >> [...] > > -1 for assignment in nonlocal and global statements from me, too. Indeed. The PEP should be updated to be clear that that part was never implemented (referencing Raymond's post for the reasons why). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Range __contains__ and objects with __index__ methods
Bah. I meant to send this to the list. (I suspect that Nick also meant to send his reply to the list.) On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson wrote: > On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan wrote: >> The symmetry only breaks for a class that breaks the invariant: >> >> x == operator.index(x) >> >> Failing to guarantee that invariant seems to violate the whole spirit >> of operator.index(). > > Agreed. (Though one also needs transitivity, symmetry, etc., of > equality, since what we really need is that x == y is interchangeable > with operator.index(x) == y.) > >> Perhaps this is what we should be documenting as >> the true distinguishing feature between the intended semantics of >> __index__ and the semantics of __int__? > > Hmm. Perhaps. For me, this doesn't fully capture the intent of > __index__, though. > > So the semantics (ignoring performance issues for now) would become: > > def range_contains(self, x) > try: > i = operator.index(x) > except TypeError: > i = x > return any(i == y for y in self) > > ? > > This change sounds fine to me; it would be good to have a > documentation note somewhere indicating that the range implementation > assumes x == index(x), though. This might belong in the range > documentation, or perhaps the __index__ method documentation could > indicate that some builtins might have unpredictable behaviour if the > identity is violated. > > Mark > ___ 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] Fwd: Range __contains__ and objects with __index__ methods
.. and here's my original reply to Nick, which was also intended to go to the list. Sorry, folks. Mark -- Forwarded message -- From: Mark Dickinson Date: Mon, Dec 27, 2010 at 10:27 AM Subject: Re: [Python-Dev] Range __contains__ and objects with __index__ methods To: Nick Coghlan On Mon, Dec 27, 2010 at 12:15 AM, Nick Coghlan wrote: > Starting in Python 3.2, range() supports fast containment checking for > integers (i.e. based on an O(1) arithmetic calculation rather than an > O(N) iteration through the entire sequence). > > Currently, this fast path ignores objects that implement __index__ - > they are relegated to the slow iterative search. > > This seems wrong to me [...] Is seems to me that there are two separate issues here. Namely, (1) Determine the semantics of 'x in range(...)' for an object x that implements __index__, and (2) implement the containment check efficiently. At the moment, it looks as though the __index__ method is ignored entirely for the containment check, so you're proposing a change in semantics. If/when that change in semantics is made, fixing up the code to do the containment check efficiently seems like it should be a straightforward task. With the proposed change in semantics, the simple definition (x in range(...) iff x == y for some element y of range(...)) no longer holds. I'm not convinced (but not unconvinced either) that it's worth breaking that simplicity. Mark ___ 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] nonlocal x = value
Am 27.12.2010 10:43, schrieb Raymond Hettinger: > FWIW, I'm entirely opposed to doing an assignment in a nonlocal definition. > > * It is easily mis-parsed by human (as shown by Georg's examples). > * It looks very much like an initialization of a local variable in many > languages, > but it is not -- the variable has already been initialized in another scope. Hah, and we'd probably get requests for a mandatory declaration of locals, ala local a = 5 for reasons of "consistency" or "explicit is better than implicit". 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] Loggers in the stdlib and logging configuration APIs
The logging configuration calls fileConfig and dictConfig disable all existing
loggers, and enable only loggers explicitly named in the configuration (and
their children). Although there is a disable_existing_loggers option for each
configuration API, which can be used to prevent disabling of existing loggers,
the default value of this option is True (for backward compatibility) and so
existing ("old") loggers are disabled by default.
This can lead to unexpected behaviour when loggers are used by the standard
library. A recent issue,
http://bugs.python.org/issue10626
relates to test_concurrent_futures failing, but only when exercised twice with a
test_logging call in between, as in
regrtest.py test_concurrent_futures test_logging test_concurrent_futures
I've fixed test_logging so that it remembers the disabled state of existing
loggers and restores it, and now the above test works fine. However, since
recent changes in logging, we are expecting to use it to e.g. display messages
on stderr when exceptions can't be raised in stdlib code. Thus, I think I may
need to change the way disabling of loggers works, so I wanted to get some
feedback from python-dev both about possible approaches and when to apply them
(With 3.2 so close to release I'm not proposing to do anything precipitate, just
raising the issue for discussion).
Essentially, some or all of the loggers in the stdlib itself should perhaps be
immune to the "disable existing loggers" logic. Otherwise, a fileConfig() or
dictConfig() call with default semantics will prevent a stdlib message (logged
when exceptions can't be raised) from being displayed, unless a user explicitly
names those stdlib loggers in their configuration. This is not practical because
users would need to update their configurations whenever a new logger appeared
in the stdlib. Some possible approaches are:
1. Change the default configuration behaviour so that by default, existing
loggers are NOT disabled. This is of course strongly backwards-incompatible, but
would it make sense to consider it for 3.3? Perhaps we should add a warning?
2. Change the disabling logic so that it never disables stdlib loggers. This
raises the question of how to identify them, and there are several loggers in
the stdlib in 3.2:
"py.warnings" (used by the logging package when warnings are redirected to
logging),
"concurrent.futures",
"http.cookiejar",
"multiprocessing"
However, it would be good to have some consistency of naming stdlib loggers
- perhaps using __name__ as is recommended practice for library and application
developers, but with a prefix such as "py." to indicate that it's a part of the
stdlib. This would make the disabling logic change easier as it could just check
the "py." prefix rather than have an internal list of logger names, which would
need more maintenance and be more error-prone.
There are quite possibly other approaches I haven't thought of. I'd be grateful
for your suggestions, as I'd like to minimise the impact on users, while making
it easy to add more logging to the stdlib.
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
[Python-Dev] Issue #6210: Exception Chaining missing method for suppressing context
I see the last comment was added on the 4th. Where should continued discussion take place -- bug-tracker, python-dev, ... ? ~Ethan~ ___ 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] Issue #6210: Exception Chaining missing method for suppressing context
On Mon, Dec 27, 2010 at 13:37, Ethan Furman wrote: > I see the last comment was added on the 4th. > > Where should continued discussion take place -- bug-tracker, python-dev, > ... ? > > ~Ethan~ Preferably on the bug tracker as to keep any discussion attached to the issue. If the discussion becomes stalled for reasons other than time, a discussion here might be warranted. ___ 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] Loggers in the stdlib and logging configuration APIs
On 12/27/2010 7:29 AM, Vinay Sajip wrote:
The logging configuration calls fileConfig and dictConfig disable all existing
loggers, and enable only loggers explicitly named in the configuration (and
their children). Although there is a disable_existing_loggers option for each
configuration API, which can be used to prevent disabling of existing loggers,
the default value of this option is True (for backward compatibility) and so
existing ("old") loggers are disabled by default.
Good that you recognized the bigger issue than 10626, and are wanting to
address it.
It would be interesting to hear the use case for calling fileConfig
and/or dictConfig and/or basicConfig more than once anyway (although I
guess basicConfig doesn't disable anything). That might shed some light
on the approach that should be taken.
My "intuitive" thought about the matter is that loggers, once enabled,
shouldn't be disabled except explicitly by name, not implicitly by a
flag parameter. So I'd expect a parameter that takes a list of loggers
to disable, rather than a flag whose default value disables all of
them. Of course this doesn't address the how and why of backward
compatibility needs.
Part of the problem, perhaps, is that stdlib loggers might be enabled
before the application gets to its logging configuration call, and those
would then be disabled accidentally.
As I prepare to add logging to my web application this week, I've only
found the need to initialize logging in one place and at one time... I
doubt that any of the loggers you mentioned as being in the 3.2 stdlib
will have been enabled by then, so I'll not have a problem, but if they
proliferate, I could eventually in future versions. Granted, my
application will likely be one of the simpler applications of logging,
at least initially.
While I agree it would be nice to have a stdlib logger naming convention
of some sort, I don't think the naming convention should be used to
implicitly not disable particular loggers. The only difference between
stdlib and 3rd party libraries is whether they've become stable enough
and useful enough for the whole Python community; many 3rd party
libraries are quite stable enough and useful enough for particular
applications, and could have similar issues as the stdlib regarding
logger configuration.
Having an API to disable loggers using an explicit list would require a
corresponding API to obtain from logging the list of currently enabled
loggers, and perhaps currently disabled ones as well? That way, if an
application truly wanted to disable all currently enabled loggers, they
would have an easy way to know the list... and perhaps the list of
loggers they disable during configuration should be the first thing that
is logged as a result of the xxxConfig API? Then, at least, they would
not be ignorant of the accidental disabling. I guess even if the
parameter were left as a default flag to turn off all loggers, if the
list were logged, that would be alerting. But some applications may not
expect such a log entry but maybe that is the least instrusive
backwards-compatible action that can be taken, because if an application
does configure logging, they likely do expect to have log messages to
view/process.
___
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] Column offsets for attribute nodes
Glenn wrote:
> [...] but maybe bar at 4 and baz at 8 would be even better.
> In other words, I don't think pointing at the "." is useful? [...]
Hi,
here's a patch which results in what Glenn Linderman suggested:
--- python-orig/Python/ast.c 2010-10-19 03:22:07.0 +0200
+++ python-new/Python/ast.c 2010-12-27 20:33:55.0 +0100
@@ -1615,7 +1615,7 @@
if (!attr_id)
return NULL;
return Attribute(left_expr, attr_id, Load,
- LINENO(n), n->n_col_offset, c->c_arena);
+ LINENO(CHILD(n, 1)), CHILD(n,
1)->n_col_offset, c->c_arena);
}
else {
REQ(CHILD(n, 0), LSQB);
@@ -1742,8 +1742,6 @@
tmp = ast_for_trailer(c, ch, e);
if (!tmp)
return NULL;
-tmp->lineno = e->lineno;
-tmp->col_offset = e->col_offset;
e = tmp;
}
if (TYPE(CHILD(n, NCH(n) - 1)) == factor) {
This gives 0, 4, 8 as column offsets for foo.bar.baz and 0, 6, 14 for
foo. bar.baz, i.e. points to the beginning of the attribute
identifier.
What do you think?
Bye,
Sven
2010/12/27 Nick Coghlan :
> On Mon, Dec 27, 2010 at 9:34 AM, Benjamin Peterson
> wrote:
>> 2010/12/26 Sven Brauch :
>>> In that discussion, there's been different opinions about which
>>> behaviour is better; main arguments were "consistency" for the current
>>> and "usefulness" for the suggested behaviour. It has been proposed to
>>> ask the question on this list, that's why I'm doing that now. :)
>>
>> My argument against this change is that an attribute includes the
>> expression from which the attribute is being taken. This is consistent
>> with subscripts and calls, which both have the lineno and col_offset
>> of their source expressions.
>
> I'd like to see the impact on existing uses of this information
> (primarily SyntaxErrors) before forming a firm opinion, but my initial
> inclination is that retaining the column information for the
> subattribute names is a better option.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [email protected] | Brisbane, Australia
>
___
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] r87518 - python/branches/py3k/Parser/tokenizer.c
Am 27.12.2010 21:12, schrieb victor.stinner:
> Author: victor.stinner
> Date: Mon Dec 27 21:12:13 2010
> New Revision: 87518
>
> Log:
> Issue #10778: decoding_fgets() decodes the filename from the filesystem
> encoding instead of UTF-8.
>
>
> Modified:
>python/branches/py3k/Parser/tokenizer.c
>
> Modified: python/branches/py3k/Parser/tokenizer.c
> ==
> --- python/branches/py3k/Parser/tokenizer.c (original)
> +++ python/branches/py3k/Parser/tokenizer.c Mon Dec 27 21:12:13 2010
> @@ -545,6 +545,7 @@
> {
> char *line = NULL;
> int badchar = 0;
> +PyObject *filename;
> for (;;) {
> if (tok->decoding_state == STATE_NORMAL) {
> /* We already have a codec associated with
> @@ -585,12 +586,16 @@
> if (badchar) {
> /* Need to add 1 to the line number, since this line
> has not been counted, yet. */
> -PyErr_Format(PyExc_SyntaxError,
> -"Non-UTF-8 code starting with '\\x%.2x' "
> -"in file %.200s on line %i, "
> -"but no encoding declared; "
> -"see http://python.org/dev/peps/pep-0263/ for details",
> -badchar, tok->filename, tok->lineno + 1);
> +filename = PyUnicode_DecodeFSDefault(tok->filename);
> +if (filename != NULL) {
> +PyErr_Format(PyExc_SyntaxError,
> +"Non-UTF-8 code starting with '\\x%.2x' "
> +"in file %.200U on line %i, "
> +"but no encoding declared; "
> +"see http://python.org/dev/peps/pep-0263/ for details",
> +badchar, filename, tok->lineno + 1);
> +Py_DECREF(filename);
> +}
Hmm, and in case decoding fails, we return a Unicode error (without context)
instead of a syntax error? Doesn't seem like a good trade-off when the file
name is just displayed in a message.
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] r87518 - python/branches/py3k/Parser/tokenizer.c
Le lundi 27 décembre 2010 à 22:22 +0100, Georg Brandl a écrit : > Am 27.12.2010 21:12, schrieb victor.stinner: > > Author: victor.stinner > > Date: Mon Dec 27 21:12:13 2010 > > New Revision: 87518 > > > > Log: > > Issue #10778: decoding_fgets() decodes the filename from the filesystem > > encoding instead of UTF-8. > > > Hmm, and in case decoding fails, we return a Unicode error (without context) > instead of a syntax error? Yes, but it is very unlikely. I don't see in which case the decoder can fail. But a memory error can occur. > Doesn't seem like a good trade-off when the file name is just displayed in a > message. What do you suggest? -- ___ 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] r87518 - python/branches/py3k/Parser/tokenizer.c
(oops, I posted an incomplete message, stupid mailer) Le lundi 27 décembre 2010 à 22:22 +0100, Georg Brandl a écrit : > Am 27.12.2010 21:12, schrieb victor.stinner: > > Author: victor.stinner > > Date: Mon Dec 27 21:12:13 2010 > > New Revision: 87518 > > > > Log: > > Issue #10778: decoding_fgets() decodes the filename from the filesystem > > encoding instead of UTF-8. > > > Hmm, and in case decoding fails, we return a Unicode error (without context) > instead of a syntax error? Yes, but it is very unlikely. I don't see in which case the decoder can fail. But a memory error can occur. > Doesn't seem like a good trade-off when the file name is just displayed in a > message. What do you suggest? -- Prepare the decoded filename in PyParser_ParseStringFlagsFilenameEx() and PyParser_ParseFileFlagsEx() avoids this issue. Victor ___ 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] os.getpriority() and os.setpriority()
Hi all, after having implemented something very similar in psutil: http://code.google.com/p/psutil/issues/detail?id=142 ...I decided to contribute a patch for exposing getpriority() and setpriority() system calls in the os module: http://bugs.python.org/issue10784 This was also raised some time ago: http://mail.python.org/pipermail/python-ideas/2009-April/004028.html ...and it seems feedbacks were positive. I think it would be nice to have Windows equivalents (GetPriorityClass / SetPriorityClass) as well but I'm not sure how since their notation is different. Regards, --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ 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] r87504 - in python/branches/py3k: Doc/c-api/exceptions.rst Include/pyerrors.h Include/warnings.h
On Mon, 27 Dec 2010 02:49:27 +0100, victor.stinner wrote: > Author: victor.stinner > Date: Mon Dec 27 02:49:26 2010 > New Revision: 87504 > > Log: > Issue #9738: Document encodings of error and warning functions > > Modified: >python/branches/py3k/Doc/c-api/exceptions.rst >python/branches/py3k/Include/pyerrors.h >python/branches/py3k/Include/warnings.h > > Modified: python/branches/py3k/Doc/c-api/exceptions.rst > == > --- python/branches/py3k/Doc/c-api/exceptions.rst (original) > +++ python/branches/py3k/Doc/c-api/exceptions.rst Mon Dec 27 02:49:26 2010 > @@ -148,7 +148,8 @@ > This function sets the error indicator and returns *NULL*. *exception* > should be a Python exception class. The *format* and subsequent > parameters help format the error message; they have the same meaning and > - values as in :c:func:`PyUnicode_FromFormat`. > + values as in :c:func:`PyUnicode_FromFormat`. *format* is an ASCII-encoding > + string. ASCII-encoded string, or ASCII encoding-string? > .. c:function:: int PyErr_WarnFormat(PyObject *category, Py_ssize_t > stack_level, const char *format, ...) > > Function similar to :c:func:`PyErr_WarnEx`, but use > - :c:func:`PyUnicode_FromFormat` to format the warning message. > + :c:func:`PyUnicode_FromFormat` to format the warning message. *format* is > + an ASCII-encoded string. So, the former, I'd guess :) -- R. David Murray www.bitdance.com ___ 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] r87505 - in python/branches/py3k: Doc/c-api/unicode.rst Include/unicodeobject.h
On Mon, 27 Dec 2010 02:49:29 +0100, victor.stinner wrote: > Author: victor.stinner > Date: Mon Dec 27 02:49:29 2010 > New Revision: 87505 > > Log: > Issue #9738: document encodings of unicode functions > > Modified: >python/branches/py3k/Doc/c-api/unicode.rst >python/branches/py3k/Include/unicodeobject.h > > Modified: python/branches/py3k/Doc/c-api/unicode.rst > == > --- python/branches/py3k/Doc/c-api/unicode.rst(original) > +++ python/branches/py3k/Doc/c-api/unicode.rstMon Dec 27 02:49:29 2010 > @@ -1063,7 +1063,8 @@ > .. c:function:: int PyUnicode_CompareWithASCIIString(PyObject *uni, char > *string) > > Compare a unicode object, *uni*, with *string* and return -1, 0, 1 for > less > - than, equal, and greater than, respectively. > + than, equal, and greater than, respectively. *string* is an ASCII-encoded > + string (it is interpreted as ISO-8859-1). Does it mean anything to say that an ASCII string is interpreted as ISO-8859-1? If it is ASCII-encoded it shouldn't have any bytes with the 8th bit set, leaving no room for interpretation. So presumably you mean it is (treated as) an ISO-8859-1 encoded string, despite the function name? -- R. David Murray www.bitdance.com ___ 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] Loggers in the stdlib and logging configuration APIs
On Tue, Dec 28, 2010 at 1:29 AM, Vinay Sajip wrote: > However, it would be good to have some consistency of naming stdlib > loggers > - perhaps using __name__ as is recommended practice for library and > application > developers, but with a prefix such as "py." to indicate that it's a part of > the > stdlib. This would make the disabling logic change easier as it could just > check > the "py." prefix rather than have an internal list of logger names, which > would > need more maintenance and be more error-prone. Unfortunately, the "py" package already claimed that namespace, so it isn't really free for us to use in the standard library (even the current "py.warnings" for redirected warnings may be misleading, as it may give users the impression that package is involved somewhere along the line). It is probably best just to go with the "__name__" convention and not worry about being able to draw a clean distinction between "standard library" and "third party" (that distinction doesn't exist in the module heirarchy, so it isn't really reasonable to expect it to exist in the logging heirarchy). However, rather than a manually maintained list of low level loggers, it may be feasible to just have a flag we can set on loggers that makes them immune to the default implicit disabling. Then the config calls can support three levels of logger disabling: - leave all existing loggers enabled (existing option) - leave only flagged loggers enabled (new default behaviour) - disable all loggers not mentioned explicitly (new option) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
