Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?
"Martin v. Löwis", 19.02.2012 23:24: >> When compiling for PyPy, Cython therefore needs a way to tell PyPy about >> any changes. For the tstate->curexc_* fields, there are the two functions >> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official" >> functions for the exc_* fields? Maybe PyErr_FetchLast() and >> PyErr_RestoreLast()? > > I wouldn't call the functions *Last, as this may cause confusion with > sys.last_*. I'm also unsure why the current API uses this Fetch/Restore > pair of functions where Fetch clears the variables. A Get/Set pair of > functions would be more natural, IMO (where Get returns "new" > references). This would give PyErr_GetExcInfo/PyErr_SetExcInfo. Ok, I added a tracker ticket and I'm working on a patch. http://bugs.python.org/issue14098 Stefan ___ 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] http://pythonmentors.com/
Brian Curtin writes: > On Thu, Feb 23, 2012 at 01:15, Stephen J. Turnbull > wrote: > > Brian Curtin writes: > > > > > If you want to contribute to development, I think you'll know that a > > > link about development is relevant. > > > > For values of "you" in "experienced programmers", yes. But > > translators and tech writers don't consider what they do to be > > "development." > > I don't know what this is saying, but I'll guess it's some suggestion > that we should still name the link "Contributing". No, it's saying that there are a lot of potential contributors for whom "Core Development" is pretty obviously not where they want to go. There should be a link that is the obvious place for them to go, and there currently isn't one. I don't have a problem with the presence of a "core development" link that goes to the devguide. I do have a problem with failing to invite people who are not at present interested in contributing code or money to contribute what they have. The next question is how many links do we want in that sidebar; I think there may already be too many. But I'm not a web designer to have a strong opinion on that. ___ 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] Exceptions in LOAD_GLOBAL and LOAD_NAME
The code below causes different behaviour for LOAD_GLOBAL and LOAD_NAME.
Which is correct?
Should exceptions raised in the equality test be converted to a
NameError or just propogated?
Cheers,
Mark.
-
import sys
class S(str):
pass
def eq_except(self, other):
if isinstance(other, str):
raise TypeError("Cannot compare S and str")
globals()[S("a")] = 0
S.__eq__ = eq_except
def f():
print(a)
try:
f()
except:
print(sys.exc_info()[1])
try:
print(a)
except:
print(sys.exc_info()[1])
--
Output:
TypeError('Cannot compare S and str',)
NameError("name 'a' is not defined",)
___
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] Exceptions in LOAD_GLOBAL and LOAD_NAME
On Thu, Feb 23, 2012 at 8:12 PM, Mark Shannon wrote: > Should exceptions raised in the equality test be converted to a NameError or > just propogated? Our general trend has been towards letting such exceptions escape the operation that caused them rather than implicitly suppressing them. In this case, the NameError message that results is also misleading (since "print(globals().keys())" will definitely show an 'a' entry). Given the effort you have to go to to trigger it, I'd consider fixing this low priority, but I agree that the conversion of the TypeError to NameError is a bug (likely resolved by adding a KeyError exception type check in the appropriate location). 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] Exceptions in LOAD_GLOBAL and LOAD_NAME
Nick Coghlan wrote: On Thu, Feb 23, 2012 at 8:12 PM, Mark Shannon wrote: Should exceptions raised in the equality test be converted to a NameError or just propogated? Our general trend has been towards letting such exceptions escape the operation that caused them rather than implicitly suppressing them. In this case, the NameError message that results is also misleading (since "print(globals().keys())" will definitely show an 'a' entry). Given the effort you have to go to to trigger it, I'd consider fixing this low priority, but I agree that the conversion of the TypeError to NameError is a bug (likely resolved by adding a KeyError exception type check in the appropriate location). It is not a difficult fix. Just replacing calls to PyDict_GetItem with PyDict_GetItemWithError and raising NameError only if no Exception has occurred. Cheers, 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] cpython: Refactor importlib to make it easier to re-implement in C.
On Thu, 23 Feb 2012 16:18:19 +0100
brett.cannon wrote:
> def _sanity_check(name, package, level):
> """Verify arguments are "sane"."""
> +if not hasattr(name, 'rpartition'):
> +raise TypeError("module name must be str, not {}".format(type(name)))
Why don't you simply use isinstance()?
(bytes objects also have rpartition())
Regards
Antoine.
___
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] peps: Switch back to named functions, since the Ellipsis version degenerated badly
On Wed, Feb 22, 2012 at 10:22 AM, nick.coghlan
wrote:
> + in x = weakref.ref(target, report_destruction)
> + def report_destruction(obj):
> print("{} is being destroyed".format(obj))
> +If the repetition of the name seems especially annoying, then a throwaway
> +name like ``f`` can be used instead::
> + in x = weakref.ref(target, f)
> + def f(obj):
> + print("{} is being destroyed".format(obj))
I still feel that the helper function (or class) is subordinate, and
should be indented. Thinking of "in ..." as a decorator helps, but
makes it seem that the helper function is the important part (which it
sometimes is...)
I understand that adding a colon and indent has its own problems, but
... I'm not certain this is better, and I am certain that the desire
for indentation is strong enough to at least justify discussion in the
PEP.
-jJ
___
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] cpython: Refactor importlib to make it easier to re-implement in C.
On Thu, Feb 23, 2012 at 10:43, Antoine Pitrou wrote:
> On Thu, 23 Feb 2012 16:18:19 +0100
> brett.cannon wrote:
> > def _sanity_check(name, package, level):
> > """Verify arguments are "sane"."""
> > +if not hasattr(name, 'rpartition'):
> > +raise TypeError("module name must be str, not
> {}".format(type(name)))
>
> Why don't you simply use isinstance()?
> (bytes objects also have rpartition())
>
I think I was on a interface-conformance kick at the time and didn't want
to restrict to a specific type over a specific interface. But since
subclasses is not exactly complicated I can change this (which will also
match potential C code more with a PyUnicode_Check()).
___
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] Proposing an alternative to PEP 410
I've been meditating on the whole os.stat mtime representation thing. Here's a possible alternative approach. * Improve datetime.datetime objects so they support nanosecond resolution, in such a way that it's 100% painless to make them even more precise in the future. * Add support to datetime objects that allows adding and subtracting ints and floats as seconds. This behavior is controllable with a flag on the object--by default this behavior is off. * Support accepting naive datetime.datetime objects in all functions that accept a timestamp in os (utime etc). * Change the result of os.stat to be a custom class rather than a PyStructSequence. Support the sequence protocol on the custom class but mark it PendingDeprecation, to be removed completely in 3.5. (I can't take credit for this idea; MvL suggested it to me once while we were talking about this issue. Now that the os.stat object has named fields, who uses the struct unpacking anymore?) * Add support for setting "stat_float_times=2" (or perhaps "stat_float_times=datetime.datetime" ?) to enable returning st_[acm]time as naive datetime.datetime objects--specifically, ones that allow addition and subtraction of ints and floats. The value would be similar to calling datetime.datetime.fromdatetime() on the current float timestamp, but would preserve all available precision. * Add a new parameter to functions that produce stat-like timestamps to explicitly specify the type of the timestamps (float or datetime), as proposed in PEP 410. I realize datetime objects aren't a drop-in replacement for floats (or ints). In particular their str/repr representations are much more ornate. So I'd expect some breakage. Personally I think the adding/subtracting ints change is a tiny bit smelly--but this is a practicality beating purity thing. I propose making it non-default behavior just to minimize the effects of the change. Similarly, I realize os.stat_float_times was always a bit of a hack, what with it being global state and all. However the approach has the virtue of having worked in the past. I disagree with PEP 410's conclusions about the suitability of datetime as a timestamp object. I think "naive" datetime objects are a perfect fit. Specficially addressing PEP 410's concerns: * I don't propose doing anything about the other functions that have no explicit start time; I'm only proposing changing the functions that deal with timestamps. (Perhaps the right thing for epoch-less times like time.clock would be timedelta? But I think we can table this discussion for now.) * "You can't compare naive and non-naive datetimes." So what? The existing timestamp from os.stat is a float, and you can't compare floats and non-naive datetimes. How is this an issue? Perhaps someone else can propose something even better, //arry/ ___ 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] Proposing an alternative to PEP 410
I rejected datetime.datetime because I want to get nanosecond resolution for time and os modules, not only for the os module. If we choose to only patch the os module (*stat() and *utime*() functions), datetime.datetime would be meaningful (e.g. it's easier to format datetime for an human, than a Epoch timestamp). I don't think that it's a real issue that datetime is not fully compatible with float. If os.stat() continues to return float by default, programs asking explicitly for datetime would be prepared to handle this type. I have the same rationale with Decimal :-) I don't think that there is a need to support datetime+int or datetime-float, there is already the timedelta type which is well defined. For os.stat(), you should use the UTC timezone, not a naive datetime. > * Add a new parameter to functions that produce stat-like timestamps to > explicitly specify the type of the timestamps (float or datetime), > as proposed in PEP 410. What is a stat-like timestamp? Which functions are concerned? > Similarly, I realize os.stat_float_times was always a bit of a hack, what > with it being global state and all. However the approach has the virtue of > having worked in the past. A global switch to get timestamps as datetime or Decimal would break libraries and programs unable to handle these types. I prefer adding an argument to os.*stat() functions to avoid border effects. Read also: http://www.python.org/dev/peps/pep-0410/#add-a-global-flag-to-change-the-timestamp-type > Specficially addressing PEP 410's concerns: > > * I don't propose doing anything about the other functions that have no > explicit start time; I'm only proposing changing the functions that deal > with timestamps. (Perhaps the right thing for epoch-less times like > time.clock would be timedelta? But I think we can table this discussion > for now.) We may choose a different solution for the os.stat()/os.utime() and for the others functions (see the PEP 410 for the full list). But I would prefer an unified solution to provide nanosecond resolution in all modules. It would avoid to have to support two new types for example. 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
Re: [Python-Dev] Proposing an alternative to PEP 410
On 02/23/2012 02:35 PM, Victor Stinner wrote: I rejected datetime.datetime because I want to get nanosecond resolution for time and os modules, not only for the os module. If we choose to only patch the os module (*stat() and *utime*() functions), datetime.datetime would be meaningful (e.g. it's easier to format datetime for an human, than a Epoch timestamp). I think a piecemeal approach would be better. I'm aware of a specific problem with os.stat / os.utime--the loss of precision problem that's already been endlessly discussed. Is there a similar problem with these other functions? I don't think that there is a need to support datetime+int or datetime-float, there is already the timedelta type which is well defined. I suggest this because I myself have written (admittedly sloppy) code that assumed it could perform simple addition with st_mtime. Instead of finding out the current timestamp and writing that out properly, I occasionally read in the file's mtime, add a small integer (or even smaller float), and write it back out. For os.stat(), you should use the UTC timezone, not a naive datetime. Why is that more appropriate? IIUC, timestamps ignore leap seconds and strictly represent "seconds since the epoch". In order to correctly return a time in the UTC time zone we'd have to adjust for leap seconds. Naive datetimes bask in their happy ignorance of such complexities. //arry/ ___ 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] Proposing an alternative to PEP 410
On Thu, Feb 23, 2012 at 3:47 PM, Larry Hastings wrote: > On 02/23/2012 02:35 PM, Victor Stinner wrote: > > For os.stat(), you should use the UTC timezone, not a naive datetime. > > Why is that more appropriate? IIUC, timestamps ignore leap seconds and > strictly represent "seconds since the epoch". In order to correctly return > a time in the UTC time zone we'd have to adjust for leap seconds. Naive > datetimes bask in their happy ignorance of such complexities. You seem to have the meaning of "ignore leap seconds" backwards. POSIX timestamps are not *literally* seconds since the epoch. They are *non-leap* seconds since the epoch, which is just what you want. IOW the simple calculation ignoring leap seconds (found e.g. in calendar.py) will always produce the right value. -- --Guido van Rossum (python.org/~guido) ___ 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] requirements for moving __import__ over to importlib?
I just tried this and I get a str/bytes issue. I also think your setup3k.py command is missing ``build`` and your build/scripts-3.2 is missing ``/hg``. On Wed, Feb 22, 2012 at 19:26, Éric Araujo wrote: > Hi Brett, > > I think this message went unanswered, so here’s a late reply: > > Le 07/02/2012 23:21, Brett Cannon a écrit : > > On Tue, Feb 7, 2012 at 15:28, Dirkjan Ochtman > wrote: > >> [...] > >> Anyway, I think there was enough of a python3 port for Mercurial (from > >> various GSoC students) that you can probably run some of the very > >> simple commands (like hg parents or hg id), which should be enough for > >> your purposes, right? > > > > Possibly. Where is the code? > > # get Mercurial from a repo or tarball > hg clone http://selenic.com/repo/hg/ > cd hg > > # convert files in place (don’t commit after this :) > python3.2 contrib/setup3k.py > > # the makefile is not py3k-aware, need to run manually > # the current stable head fails with a TypeError for me > PYTHONPATH=. python3.2 build/scripts-3.2 > > Cheers > ___ 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] cpython (3.2): logging: Added locking in flush() and close() handler methods. Thanks to Fayaz
On Thu, Feb 23, 2012 at 12:04 PM, vinay.sajip wrote: > http://hg.python.org/cpython/rev/b2adcd90e656 > changeset: 75211:b2adcd90e656 > branch: 3.2 > parent: 75200:85d08a1ba74e > user: Vinay Sajip > date: Thu Feb 23 19:45:52 2012 + > summary: > logging: Added locking in flush() and close() handler methods. Thanks to > Fayaz Yusuf Khan for the suggestion. > > files: > Lib/logging/__init__.py | 24 +--- > Lib/logging/handlers.py | 40 +++- > 2 files changed, 35 insertions(+), 29 deletions(-) > > > diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py > --- a/Lib/logging/__init__.py > +++ b/Lib/logging/__init__.py > @@ -1,4 +1,4 @@ > -# Copyright 2001-2010 by Vinay Sajip. All Rights Reserved. > +# Copyright 2001-2012 by Vinay Sajip. All Rights Reserved. > # > # Permission to use, copy, modify, and distribute this software and its > # documentation for any purpose and without fee is hereby granted, > @@ -16,9 +16,9 @@ > > """ > Logging package for Python. Based on PEP 282 and comments thereto in > -comp.lang.python, and influenced by Apache's log4j system. > +comp.lang.python. > > -Copyright (C) 2001-2011 Vinay Sajip. All Rights Reserved. > +Copyright (C) 2001-2012 Vinay Sajip. All Rights Reserved. > > To use, simply 'import logging' and log away! > """ > @@ -917,8 +917,9 @@ > """ > Flushes the stream. > """ > - if self.stream and hasattr(self.stream, "flush"): > - self.stream.flush() > + with self.lock: > + if self.stream and hasattr(self.stream, "flush"): > + self.stream.flush() I don't know if anyone actually builds Python without thread support anymore, but if so, self.lock will be set to None and these "with self.lock"s will fail. Perhaps change lock = None to self.lock = some dummy duck typed lock that supports use as a context manager and acquire/release calls? > > def emit(self, record): > """ > @@ -969,12 +970,13 @@ > """ > Closes the stream. > """ > - if self.stream: > - self.flush() > - if hasattr(self.stream, "close"): > - self.stream.close() > - StreamHandler.close(self) > - self.stream = None > + with self.lock: > + if self.stream: > + self.flush() > + if hasattr(self.stream, "close"): > + self.stream.close() > + StreamHandler.close(self) > + self.stream = None > > def _open(self): > """ > diff --git a/Lib/logging/handlers.py b/Lib/logging/handlers.py > --- a/Lib/logging/handlers.py > +++ b/Lib/logging/handlers.py > @@ -1,4 +1,4 @@ > -# Copyright 2001-2010 by Vinay Sajip. All Rights Reserved. > +# Copyright 2001-2012 by Vinay Sajip. All Rights Reserved. > # > # Permission to use, copy, modify, and distribute this software and its > # documentation for any purpose and without fee is hereby granted, > @@ -16,10 +16,9 @@ > > """ > Additional handlers for the logging package for Python. The core package is > -based on PEP 282 and comments thereto in comp.lang.python, and influenced by > -Apache's log4j system. > +based on PEP 282 and comments thereto in comp.lang.python. > > -Copyright (C) 2001-2010 Vinay Sajip. All Rights Reserved. > +Copyright (C) 2001-2012 Vinay Sajip. All Rights Reserved. > > To use, simply 'import logging.handlers' and log away! > """ > @@ -554,10 +553,11 @@ > """ > Closes the socket. > """ > - if self.sock: > - self.sock.close() > - self.sock = None > - logging.Handler.close(self) > + with self.lock: > + if self.sock: > + self.sock.close() > + self.sock = None > + logging.Handler.close(self) > > class DatagramHandler(SocketHandler): > """ > @@ -752,9 +752,10 @@ > """ > Closes the socket. > """ > - if self.unixsocket: > - self.socket.close() > - logging.Handler.close(self) > + with self.lock: > + if self.unixsocket: > + self.socket.close() > + logging.Handler.close(self) > > def mapPriority(self, levelName): > """ > @@ -1095,7 +1096,8 @@ > > This version just zaps the buffer to empty. > """ > - self.buffer = [] > + with self.lock: > + self.buffer = [] > > def close(self): > """ > @@ -1145,18 +1147,20 @@ > > The record buffer is also cleared by this operation. > """ > - if self.target: > - for record in self.buffer: > - self.target.handle(record) > - self.buffer = [] > + with self.lock: > + if self.target: > + for record in self.buffer: > + self.target.handle(record) > + self.buffer = [] > > def cl
Re: [Python-Dev] [Python-checkins] cpython (3.2): logging: Added locking in flush() and close() handler methods. Thanks to Fayaz
On Thu, Feb 23, 2012 at 5:51 PM, Gregory P. Smith wrote: > On Thu, Feb 23, 2012 at 12:04 PM, vinay.sajip > wrote: >> http://hg.python.org/cpython/rev/b2adcd90e656 >> changeset: 75211:b2adcd90e656 >> branch: 3.2 >> parent: 75200:85d08a1ba74e >> user: Vinay Sajip >> date: Thu Feb 23 19:45:52 2012 + >> summary: >> logging: Added locking in flush() and close() handler methods. Thanks to >> Fayaz Yusuf Khan for the suggestion. >> >> files: >> Lib/logging/__init__.py | 24 +--- >> Lib/logging/handlers.py | 40 +++- >> 2 files changed, 35 insertions(+), 29 deletions(-) >> >> >> diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py >> --- a/Lib/logging/__init__.py >> +++ b/Lib/logging/__init__.py >> @@ -1,4 +1,4 @@ >> -# Copyright 2001-2010 by Vinay Sajip. All Rights Reserved. >> +# Copyright 2001-2012 by Vinay Sajip. All Rights Reserved. >> # >> # Permission to use, copy, modify, and distribute this software and its >> # documentation for any purpose and without fee is hereby granted, >> @@ -16,9 +16,9 @@ >> >> """ >> Logging package for Python. Based on PEP 282 and comments thereto in >> -comp.lang.python, and influenced by Apache's log4j system. >> +comp.lang.python. >> >> -Copyright (C) 2001-2011 Vinay Sajip. All Rights Reserved. >> +Copyright (C) 2001-2012 Vinay Sajip. All Rights Reserved. >> >> To use, simply 'import logging' and log away! >> """ >> @@ -917,8 +917,9 @@ >> """ >> Flushes the stream. >> """ >> - if self.stream and hasattr(self.stream, "flush"): >> - self.stream.flush() >> + with self.lock: >> + if self.stream and hasattr(self.stream, "flush"): >> + self.stream.flush() > > I don't know if anyone actually builds Python without thread support > anymore, but if so, self.lock will be set to None and these "with > self.lock"s will fail. > > Perhaps change lock = None to self.lock = some dummy duck typed lock > that supports use as a context manager and acquire/release calls? whoops. once again there I go reading the commit log in order. Looks like you already fixed this in http://hg.python.org/cpython/rev/2ab3a97d544c. thanks! :) > >> >> def emit(self, record): >> """ >> @@ -969,12 +970,13 @@ >> """ >> Closes the stream. >> """ >> - if self.stream: >> - self.flush() >> - if hasattr(self.stream, "close"): >> - self.stream.close() >> - StreamHandler.close(self) >> - self.stream = None >> + with self.lock: >> + if self.stream: >> + self.flush() >> + if hasattr(self.stream, "close"): >> + self.stream.close() >> + StreamHandler.close(self) >> + self.stream = None >> >> def _open(self): >> """ >> diff --git a/Lib/logging/handlers.py b/Lib/logging/handlers.py >> --- a/Lib/logging/handlers.py >> +++ b/Lib/logging/handlers.py >> @@ -1,4 +1,4 @@ >> -# Copyright 2001-2010 by Vinay Sajip. All Rights Reserved. >> +# Copyright 2001-2012 by Vinay Sajip. All Rights Reserved. >> # >> # Permission to use, copy, modify, and distribute this software and its >> # documentation for any purpose and without fee is hereby granted, >> @@ -16,10 +16,9 @@ >> >> """ >> Additional handlers for the logging package for Python. The core package is >> -based on PEP 282 and comments thereto in comp.lang.python, and influenced by >> -Apache's log4j system. >> +based on PEP 282 and comments thereto in comp.lang.python. >> >> -Copyright (C) 2001-2010 Vinay Sajip. All Rights Reserved. >> +Copyright (C) 2001-2012 Vinay Sajip. All Rights Reserved. >> >> To use, simply 'import logging.handlers' and log away! >> """ >> @@ -554,10 +553,11 @@ >> """ >> Closes the socket. >> """ >> - if self.sock: >> - self.sock.close() >> - self.sock = None >> - logging.Handler.close(self) >> + with self.lock: >> + if self.sock: >> + self.sock.close() >> + self.sock = None >> + logging.Handler.close(self) >> >> class DatagramHandler(SocketHandler): >> """ >> @@ -752,9 +752,10 @@ >> """ >> Closes the socket. >> """ >> - if self.unixsocket: >> - self.socket.close() >> - logging.Handler.close(self) >> + with self.lock: >> + if self.unixsocket: >> + self.socket.close() >> + logging.Handler.close(self) >> >> def mapPriority(self, levelName): >> """ >> @@ -1095,7 +1096,8 @@ >> >> This version just zaps the buffer to empty. >> """ >> - self.buffer = [] >> + with self.lock: >> + self.buffer = [] >> >> def close(self): >> """ >> @@ -1145,18 +1147,20 @@ >> >> The record buffer is also cleared by this ope
