Re: [Python-Dev] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod
Nick Coghlan schrieb: It would be nice if there was a similar mechanism for normal instance methods as well: method = function(some_callable) If you know you have to put something around it, what's wrong with writing method = lambda *args:some_callable(*args) If that happens often enough, you can write def function(f): return lambda *args:f(*args) 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] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod
Martin v. Löwis wrote: Nick Coghlan schrieb: It would be nice if there was a similar mechanism for normal instance methods as well: method = function(some_callable) If you know you have to put something around it, what's wrong with writing method = lambda *args:some_callable(*args) If that happens often enough, you can write def function(f): return lambda *args:f(*args) Both of those are inferior to defining a new method with the right name and arguments and a docstring directing readers to the relevant function (which is what I would do for this situation at the moment). The idea of the builtin would be to let introspection tools know that the documentation of the existing callable applies to the method as well, so that things like help(x.method) could retrieve something more useful than: help(C().method) Help on method method in module __main__: method(*args, **kwds) method of __main__.C instance Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] 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 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] dict containment annoyance
a={1:2, 3:4} [] in aTraceback (most recent call last): File stdin, line 1, in ?TypeError: list objects are unhashableimo, 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
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] [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 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] dict containment annoyance
On Sat, Aug 12, 2006, tomer filiba wrote:
a={1:2, 3:4}
[] in a
Traceback (most recent call last):
File stdin, 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
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] dict containment annoyance
tomer filiba wrote:
a={1:2, 3:4}
[] in a
Traceback (most recent call last):
File stdin, 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
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] 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 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] 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);
Modified:
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
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] 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
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] 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 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] 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 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] 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 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] 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=detailaid=1539381group_id=5470atid=305470 ___ 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
