[Python-Dev] Recent logging spew
We're getting an awful lot of these turds at the ends of test runs now: Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Code\bb_slave\trunk.peters-windows\build\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Code\bb_slave\trunk.peters-windows\build\lib\logging\__init__.py", line 1351, in shutdown h.flush() File "C:\Code\bb_slave\trunk.peters-windows\build\lib\logging\__init__.py", line 731, in flush self.stream.flush() ValueError: I/O operation on closed file Error in sys.exitfunc: Traceback (most recent call last): File "C:\Code\bb_slave\trunk.peters-windows\build\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Code\bb_slave\trunk.peters-windows\build\lib\logging\__init__.py", line 1351, in shutdown h.flush() File "C:\Code\bb_slave\trunk.peters-windows\build\lib\logging\__init__.py", line 731, in flush self.stream.flush() ValueError: I/O operation on closed file [450168 refs] program finished with exit code 0 Not sure what caused it, but suspect this: """ Author: georg.brandl Date: Fri Aug 11 09:26:10 2006 New Revision: 51206 Modified: python/trunk/Lib/logging/__init__.py python/trunk/Misc/NEWS Log: logging's atexit hook now runs even if the rest of the module has already been cleaned up. """ Anyway, can we stop this? It doesn't look like "a feature" from here ;-) ___ 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] Recent logging spew
Tim Peters wrote: > We're getting an awful lot of these turds at the ends of test runs now: > > Error in atexit._run_exitfuncs: > Not sure what caused it, but suspect this: > > """ > Author: georg.brandl > Date: Fri Aug 11 09:26:10 2006 > New Revision: 51206 > > Modified: > python/trunk/Lib/logging/__init__.py > python/trunk/Misc/NEWS > Log: > logging's atexit hook now runs even if the rest of the module has > already been cleaned up. > """ > > Anyway, can we stop this? It doesn't look like "a feature" from here ;-) If it was a feature, it couldn't have gone in right now ;-) But yes, I confirmed that that change caused it. I've now found the problem: one of the test_logging tests reassigned _handlerList, causing it to go out of sync with the handlerList stored in shutdown(). Fixed in rev. 51235. 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] dict containment annoyance
>>> a={1:2, 3:4}>>> [] in aTraceback (most recent call last): File "", line 1, in ?TypeError: list objects are unhashable>>>imo, the _expression_ should just evaluate to False instead of raising an exception.
it's a question of semantics -- i asked whether the object (a list, in this case)is contained in the dict. i didn't ask whether it's hashable or not. if the object isunhashable, then surely it's not contained in the dict, therefore the answer is
False, rather than an exception.dict.__contains__ should just swallow these exceptions, and return False.-tomer
___
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] [Python-3000] Python 2.5 release schedule (was: threading, part 2)
[added python-dev to make sure everyone sees this] On Sat, Aug 12, 2006, Josiah Carlson wrote: > > All other feature additions are too late in the Beta cycle (Beta 3 is > next week) For some reason, this is the second time I've seen this claim. Beta 3 was released August 3 and next week is rc1. We are right now in complete feature lockdown; even documenting an existing API IMO requires approval from the Release Manager. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian W. Kernighan ___ 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] dict containment annoyance
On Sat, Aug 12, 2006, tomer filiba wrote:
>
> >>>a={1:2, 3:4}
> >>>[] in a
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: list objects are unhashable
> >>>
>
> imo, the expression should just evaluate to False instead of raising an
> exception.
-1
This is seriously no different from an attempt to do
>>> a = {}
>>> a[ [] ] = 1
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. Kernighan
___
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] dict containment annoyance
tomer filiba wrote:
a={1:2, 3:4}
[] in a
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: list objects are unhashable
>
> imo, the expression should just evaluate to False instead of raising an
> exception. it's a question of semantics -- i asked whether the object
> (a list, in this case) is contained in the dict. i didn't ask whether
> it's hashable or not.
However, if it isn't hashable, asking whether it is in a dict is very
likely to be a programming error.
--
David Hopwood <[EMAIL PROTECTED]>
___
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] dict containment annoyance
[Aahz]
> -1
>
> This is seriously no different from an attempt to do
>
> >>> a = {}
> >>> a[ [] ] = 1
how so? i'm not trying to modify/store anything in a dict.
i'm only testing if a certain object is contained in the dict.
that's totally different.
imagine this:
>>> x = 6
>>> x < 2
am i trying to modify 'x' in any way? i'm only testing if x is
less than 2.
i fail to see your point
[David Hopwood]
> However, if it isn't hashable, asking whether it is in a dict is very
> likely to be a programming error.
not really. my program holds a blacklist of "bad objects", which
shouldn't be granted access to. instead of a list, i'm using a set
(performance, whatever). the "bad objects" are all hashable,
and i want to see if an arbitrary object is "good" or "bad", by looking
it up in the blacklist. the arbitrary object can be hashable or not,
that's not the question.
just like `"hello" != 2` returns True, instead of raising IncompatibleTypes,
i want `x in y` to return False when `x` is not contained in `y`
(with no regard to whether or not it's possible for `y` to contain `x`).
the logic is simple: every `x` is either contained in `y` or not.
if `x` *cannot* be contained in `y`, then the answer is a "strong no",
but that's still a "no".
-tomer
___
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] dict containment annoyance
On Sat, 12 Aug 2006 18:57:02 +0200, tomer filiba <[EMAIL PROTECTED]> wrote: > >the logic is simple: every `x` is either contained in `y` or not. >if `x` *cannot* be contained in `y`, then the answer is a "strong no", >but that's still a "no". > def blacklisted(o): try: # Is the object contained in the blacklist set? return o in _blacklistset except TypeError: # If it *cannot* be contained in the blacklist set, # then it probably isn't. return False Jean-Paul ___ 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: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c Modul
I checked in this fix for the __index__ clipping issue that's been
discussed. This patch is an improvement, but still needs some work.
Please pull out any parts you have an issue with and suggest a patch
to address your concern.
n
-- Forwarded message --
From: neal.norwitz <[EMAIL PROTECTED]>
Date: Aug 12, 2006 10:03 AM
Subject: [Python-checkins] r51236 - in python/trunk:
Doc/api/abstract.tex Include/abstract.h Include/object.h
Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c
Modules/mmapmodule.c Modules/operator.c Objects/abstract.c
Objects/classobject.c Objects/intobject.c Objects/listobject.c
Objects/longobject.c Objects/sliceobject.c Objects/stringobject.c
Objects/tupleobject.c Objects/typeobject.c Objects/unicodeobject.c
Python/ceval.c
To: [EMAIL PROTECTED]
Author: neal.norwitz
Date: Sat Aug 12 19:03:09 2006
New Revision: 51236
Modified:
python/trunk/Doc/api/abstract.tex
python/trunk/Include/abstract.h
python/trunk/Include/object.h
python/trunk/Lib/test/test_index.py
python/trunk/Misc/NEWS
python/trunk/Modules/arraymodule.c
python/trunk/Modules/mmapmodule.c
python/trunk/Modules/operator.c
python/trunk/Objects/abstract.c
python/trunk/Objects/classobject.c
python/trunk/Objects/intobject.c
python/trunk/Objects/listobject.c
python/trunk/Objects/longobject.c
python/trunk/Objects/sliceobject.c
python/trunk/Objects/stringobject.c
python/trunk/Objects/tupleobject.c
python/trunk/Objects/typeobject.c
python/trunk/Objects/unicodeobject.c
python/trunk/Python/ceval.c
Log:
Patch #1538606, Patch to fix __index__() clipping.
I modified this patch some by fixing style, some error checking, and adding
XXX comments. This patch requires review and some changes are to be expected.
I'm checking in now to get the greatest possible review and establish a
baseline for moving forward. I don't want this to hold up release if possible.
Modified: python/trunk/Doc/api/abstract.tex
==
--- python/trunk/Doc/api/abstract.tex (original)
+++ python/trunk/Doc/api/abstract.tex Sat Aug 12 19:03:09 2006
@@ -693,12 +693,31 @@
\samp{float(\var{o})}.\bifuncindex{float}
\end{cfuncdesc}
-\begin{cfuncdesc}{Py_ssize_t}{PyNumber_Index}{PyObject *o}
- Returns the \var{o} converted to a Py_ssize_t integer on success, or
- -1 with an exception raised on failure.
+\begin{cfuncdesc}{PyObject*}{PyNumber_Index}{PyObject *o}
+ Returns the \var{o} converted to a Python int or long on success or \NULL{}
+ with a TypeError exception raised on failure.
\versionadded{2.5}
\end{cfuncdesc}
+\begin{cfuncdesc}{Py_ssize_t}{PyNumber_AsSsize_t}{PyObject *o, PyObject *exc}
+ Returns \var{o} converted to a Py_ssize_t value if \var{o}
+ can be interpreted as an integer. If \var{o} can be converted to a Python
+ int or long but the attempt to convert to a Py_ssize_t value
+ would raise an \exception{OverflowError}, then the \var{exc} argument
+ is the type of exception that will be raised (usually \exception{IndexError}
+ or \exception{OverflowError}). If \var{exc} is \NULL{}, then the exception
+ is cleared and the value is clipped to \var{PY_SSIZE_T_MIN}
+ for a negative integer or \var{PY_SSIZE_T_MAX} for a positive integer.
+ \versionadded{2.5}
+\end{cfuncdesc}
+
+\begin{cfuncdesc}{int}{PyIndex_Check}{PyObject *o}
+ Returns True if \var{o} is an index integer (has the nb_index slot of
+ the tp_as_number structure filled in).
+ \versionadded{2.5}
+\end{cfuncdesc}
+
+
\section{Sequence Protocol \label{sequence}}
\begin{cfuncdesc}{int}{PySequence_Check}{PyObject *o}
Modified: python/trunk/Include/abstract.h
==
--- python/trunk/Include/abstract.h (original)
+++ python/trunk/Include/abstract.h Sat Aug 12 19:03:09 2006
@@ -758,13 +758,27 @@
*/
- PyAPI_FUNC(Py_ssize_t) PyNumber_Index(PyObject *);
+#define PyIndex_Check(obj) \
+ ((obj)->ob_type->tp_as_number != NULL && \
+PyType_HasFeature((obj)->ob_type, Py_TPFLAGS_HAVE_INDEX) && \
+(obj)->ob_type->tp_as_number->nb_index != NULL)
+
+ PyAPI_FUNC(PyObject *) PyNumber_Index(PyObject *o);
/*
-Returns the object converted to Py_ssize_t on success
-or -1 with an error raised on failure.
+Returns the object converted to a Python long or int
+or NULL with an error raised on failure.
*/
+ PyAPI_FUNC(Py_ssize_t) PyNumber_AsSsize_t(PyObject *o, PyObject *exc);
+
+ /*
+Returns the object converted to Py_ssize_t by going through
+PyNumber_Index first. If an overflow error occurs while
+converting the int-or-long to Py_ssize_t, then the second argument
+is the error-type to return. If it is NULL, then the overflow error
+is cleared and the value is clipped.
+ */
PyAPI_FUNC(PyObject *) PyNumber_Int(PyObject *o);
Modi
Re: [Python-Dev] dict containment annoyance
tomer filiba wrote:
> [Aahz]
>> -1
>>
>> This is seriously no different from an attempt to do
>>
>> >>> a = {}
>> >>> a[ [] ] = 1
>
> how so? i'm not trying to modify/store anything in a dict.
> i'm only testing if a certain object is contained in the dict.
> that's totally different.
> imagine this:
x = 6
x < 2
> am i trying to modify 'x' in any way? i'm only testing if x is
> less than 2.
The correct analogon is
>>> x = []
>>> x < 2
which currently works in Python, but won't in 3.0.
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] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
>
> +/* Return a Python Int or Long from the object item
> + Raise TypeError if the result is not an int-or-long
> + or if the object cannot be interpreted as an index.
> +*/
> +PyObject *
> PyNumber_Index(PyObject *item)
> {
> - Py_ssize_t value = -1;
> - PyNumberMethods *nb = item->ob_type->tp_as_number;
> - if (nb != NULL && HASINDEX(item) && nb->nb_index != NULL) {
> - value = nb->nb_index(item);
> + PyObject *result = NULL;
> + if (item == NULL)
> + return null_error();
> + /* XXX(nnorwitz): should these be CheckExact? Aren't subclasses ok?
> */
The idea is that the __index__() method should return an exact int or
exact long or this call will raise an error. The restriction is present
to remove the possibility of infinite recursion (though I'm not sure
where that would occur exactly).
> Modified: python/trunk/Python/ceval.c
> ==
> --- python/trunk/Python/ceval.c (original)
> +++ python/trunk/Python/ceval.c Sat Aug 12 19:03:09 2006
> @@ -3866,12 +3866,14 @@
> if (v != NULL) {
> Py_ssize_t x;
> if (PyInt_Check(v)) {
> - x = PyInt_AsSsize_t(v);
> + /* XXX(nnorwitz): I think PyInt_AS_LONG is correct,
> + however, it looks like it should be AsSsize_t.
> + There should be a comment here explaining why.
> + */
> + x = PyInt_AS_LONG(v);
Right now throughout the Python code it is assumed that
sizeof(Py_ssize_t) <= sizeof(long). Because this code is an
optimization for integers (or their sub-classes), it seems prudent to
truly make it fast rather than make a function call that will just go
through a series of checks to eventually make this very same call.
-Travis
___
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] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
> Please pull out any parts you have an issue with and suggest a patch
> to address your concern.
>
For me the only remaining concern is that quite often in the code we do this
if (PyIndex_Check(obj)) {
...
key = PyNumber_Index(obj);
or
key_value = PyNumber_AsSize_t(obj, ...)
}
else {remaining checks}
Internally PyNumber_AsSize_t makes a call to PyNumber_Index, and
PyNumber_Index also calls the PyIndex_Check as well . So, basically we
end up calling PyIndex_Check(obj) 2 times when only one check should be
necessary.
This code could be re-written to move any other type checks first and
replace the PyIndex_Check(obj) code with PyNumber_Index(obj) and error
handling but I'm not sure if that's the right way to go or if it's worth
it.
-Travis Oliphant
___
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] What is the status of file.readinto?
Alexander Belopolsky schrieb: > I know that it is a subject of an annual discussion, but since I could > not find any mention of it in the last year, let me ask this question > again: why is file.readinto "Undocumented"? It is quite useful, > particularly with numpy. > > Would a patch adding "readinto" to StringIO be acceptable? You mean, whether it would be accepted? Depends on the patch. Or are you asking whether it would be accepted now? Definitely not; no new features are allowed for Python 2.5. readinto was documented as undocumented here r23251 | tim_one | 2001-09-20 09:55:22 +0200 (Do, 20 Sep 2001) | 3 lines SF bug [#463093] File methods need doc strings. Now they don't. I can only guess why it may go away; my guess it will go away when the buffer interface is removed from Python (then it becomes unimplementable). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M
[Travis E. Oliphant] > Right now throughout the Python code it is assumed that > sizeof(Py_ssize_t) <= sizeof(long). If you find any code like that, it's a bug. Win64 is a platform where it's false. ___ 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] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M
Tim Peters wrote: > [Travis E. Oliphant] >> Right now throughout the Python code it is assumed that >> sizeof(Py_ssize_t) <= sizeof(long). > > If you find any code like that, it's a bug. Win64 is a platform where > it's false. Sorry for my confusion. I meant to say that it is assumed that sizeof(long) <= sizeof(Py_ssize_t) because the assumption is that a Python Int (stored as long) will *always* fit into into a Py_ssize_t. I think this is true on all platforms. -Travis ___ 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] What is the status of file.readinto?
On 8/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I can only guess why it may go away; my guess it will go away when > the buffer interface is removed from Python (then it becomes > unimplementable). In Py3k, the I/O APIs will be redesigned, especially the binary ones. My current idea is to have read() on a binary file return a bytes object. If readinto() continues to be necessary, please make sure the Py3k list ([email protected]) knows about your use case. We aren't quite writing up the I/O APIs in PEP-form, but when we do, that would be the right time to speak up. -- --Guido van Rossum (home page: http://www.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] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod
It ought to be called @instancemethod for a better analogy. PS Nick how's the book coming along? :-) --Guido On 8/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > It's sometimes useful to be able to use an existing callable as a method of a > new class. If the callable is a real function, this is easy. You just > including the following line in the class definition: > >method = some_callable > > However, callable objects without a function-like __get__ method can't be used > that way. So, to avoid a dependency on an implementation detail of > some_callable (i.e. whether or not it is a true function object), you have to > write: > > >def method(): >return some_callable() > > (and you can lose useful metadata in the process!) > > However, if you're adding a callable as a class method or static method, there > is OOWTDI: > >method = classmethod(some_callable) >method = staticmethod(some_callable) > > It would be nice if there was a similar mechanism for normal instance methods > as well: > >method = function(some_callable) > > This came up during the PEP 343 implementation - "context = > contextlib.closing" is a tempting thing to write in order to provide a > "x.context()" method for use in a with statement, but it doesn't actually work > properly (because closing is a class, not a function). > > Similarly, you can't create a method simply by applying functools.partial to > an existing function - the result won't have a __get__ method, so it will be > treated like a normal attribute instead of as an instance method. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.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] What is the status of file.readinto?
On 8/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Alexander Belopolsky schrieb: > > Would a patch adding "readinto" to StringIO be acceptable? > > You mean, whether it would be accepted? Depends on the patch. Here is the patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1539381&group_id=5470&atid=305470 ___ 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] Fwd: [Python-checkins] r51236 - in python/trunk: Doc/api/abstract.tex Include/abstract.h Include/object.h Lib/test/test_index.py Misc/NEWS Modules/arraymodule.c Modules/mmapmodule.c M
Travis E. Oliphant wrote: > Internally PyNumber_AsSize_t makes a call to PyNumber_Index, and > PyNumber_Index also calls the PyIndex_Check as well . So, basically we > end up calling PyIndex_Check(obj) 2 times when only one check should be > necessary. > > This code could be re-written to move any other type checks first and > replace the PyIndex_Check(obj) code with PyNumber_Index(obj) and error > handling but I'm not sure if that's the right way to go or if it's worth > it. This concern was what lead me up the garden path with the more complicated C API in my patch. I've since become convinced that compared to everything else going on, the repetition of the 3 not-NULL checks performed by that macro really isn't worth worrying about (particularly at this stage of the release cycle). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
