Re: [Python-Dev] Is this a bug?
Georg Brandl wrote: > Is this considered a bug? Sure, deleting modules from sys.modules > isn't quite common, but it happened to me on one occasion. > > Python 2.4.3 (#1, Jul 29 2006, 10:52:20) > >>> import logging > >>> import sys > >>> del logging > >>> del sys.modules['logging'] > >>> ^D > Error in atexit._run_exitfuncs: > Traceback (most recent call last): >File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs > func(*targs, **kargs) >File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown > for h in _handlerList[:]: # was _handlers.keys(): > TypeError: unsubscriptable object > Error in sys.exitfunc: > Traceback (most recent call last): >File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs > func(*targs, **kargs) >File "/usr/lib/python2.4/logging/__init__.py", line 1328, in shutdown > for h in _handlerList[:]: # was _handlers.keys(): > TypeError: unsubscriptable object I've now fixed the logging issue, but what bothers me additionally is the duplication of tracebacks here. The problem is in atexit._run_exitfuncs: exc_info = None while _exithandlers: func, targs, kargs = _exithandlers.pop() try: func(*targs, **kargs) except SystemExit: exc_info = sys.exc_info() except: import traceback print >> sys.stderr, "Error in atexit._run_exitfuncs:" traceback.print_exc() exc_info = sys.exc_info() if exc_info is not None: raise exc_info[0], exc_info[1], exc_info[2] So the last exception is always reraised and therefore also printed by call_sys_exitfunc. Is this really wanted behavior? 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] __index__ clipping
Here is my C-API proposal 1) PyIndex_Check(obj) Similar to PyIter_Check(obj) as it just checks for whether or not the object can call nb_index. Actually implemented as a macro. 2) PyObject* PyNumber_Index(obj) Simple interface around nb_index that calls it if possible and returns TypeError if not (or if the result does not end up in an exact int-or-long 3) Py_ssize_t PyNumber_AsSsize_t(obj, err) This converts the object to a Py_ssize_t by using the nb_index call if possible. The err argument is a Python error object and specifies what error should be raised should the conversion from Int-or-Long to Py_ssize_t cause Overflow. If err is NULL, then no error will be raised and the result will be clipped. Other-wise the corresponding error will be set. Internally PyExc_IndexError and PyExc_OverflowError will be the errors used. -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
[Python-Dev] PyThreadState_SetAsyncExc bug?
while working on a library for raising exceptions in the context
of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
if i raise an instance, sys.exc_info() confuses the exception value for
the exception type, and the exception value is set None. if i raise the
type itself, the interpreter creates an instance internally, but then i can't
pass arguments to the exception.
code:
=
import threading
import ctypes
def _async_raise(tid, excobj):
res = ctypes.pythonapi.PyThreadState_SetAsyncExc(tid,
ctypes.py_object(excobj))
if res == 0:
raise ValueError("nonexistent thread id")
elif res > 1:
# """if it returns a number greater than one, you're in trouble,
# and you should call it again with exc=NULL to revert the effect"""
ctypes.pythonapi.PyThreadState_SetAsyncExc(tid, None)
raise SystemError("PyThreadState_SetAsyncExc failed")
class Thread(threading.Thread):
def raise_exc(self, excobj):
assert self.isAlive(), "thread must be started"
for tid, tobj in threading._active.items():
if tobj is self:
_async_raise(tid, excobj)
break
# the thread was alive when we entered the loop, but was not found
# in the dict, hence it must have been already terminated.
should we raise
# an exception here? silently ignore?
def terminate(self):
self.raise_exc(SystemExit())
if __name__ == "__main__":
import time
import sys
i_am_active = False
def f():
global i_am_active
i_am_active = True
try:
try:
while True:
time.sleep(0.01)
except IOError, ex:
print "IOError handler"
except TypeError, ex:
print "TypeError handler"
print "ex=", repr(ex)
typ, val, tb = sys.exc_info()
print "typ=", repr(typ)
print "val=", repr(val)
print "tb=", tb
finally:
i_am_active = False
t1 = Thread(target = f)
t1.start()
time.sleep(1)
t1.raise_exc(TypeError("blah blah"))
while i_am_active:
time.sleep(0.01)
print "!! thread terminated"
output:
=
TypeError handler
ex= None
typ= # should be the type
val= None # should be the instance
tb=
!! thread terminated
if i change:
t1.raise_exc(TypeError("blah blah"))
to:
t1.raise_exc(TypeError)
i get:
=
TypeError handler
ex=
typ=
val=
tb=
!! thread terminated
but then of course i can't pass arguments to the exception
-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 suppressing exceptions
Hi, On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote: > > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote: > > > I'm in favour of having this __eq__ just return False. I don't think > > > the warning is necessary, (...) > > > > +1 > > Can you explain why you believe that no warning is necessary? Ah... mostly out of ignorance, I fear. I did not realize there were strange cases like u"\xff" == "\xff". I will leave this to more unicode-minded people to decide, but I'm still definitely of the idea that the __eq__ should not raise an exception. A bientot, Armin ___ 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] PyThreadState_SetAsyncExc bug?
opened a new bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1538556&group_id=5470&atid=105470
On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
> if i raise an instance, sys.exc_info() confuses the exception value for
> the exception type, and the exception value is set None. if i raise the
> type itself, the interpreter creates an instance internally, but then i can't
> pass arguments to the exception.
>
> code:
> =
> import threading
> import ctypes
>
>
> def _async_raise(tid, excobj):
> res = ctypes.pythonapi.PyThreadState_SetAsyncExc(tid,
> ctypes.py_object(excobj))
> if res == 0:
> raise ValueError("nonexistent thread id")
> elif res > 1:
> # """if it returns a number greater than one, you're in trouble,
> # and you should call it again with exc=NULL to revert the effect"""
> ctypes.pythonapi.PyThreadState_SetAsyncExc(tid, None)
> raise SystemError("PyThreadState_SetAsyncExc failed")
>
> class Thread(threading.Thread):
> def raise_exc(self, excobj):
> assert self.isAlive(), "thread must be started"
> for tid, tobj in threading._active.items():
> if tobj is self:
> _async_raise(tid, excobj)
> break
>
> # the thread was alive when we entered the loop, but was not found
> # in the dict, hence it must have been already terminated.
> should we raise
> # an exception here? silently ignore?
>
> def terminate(self):
> self.raise_exc(SystemExit())
>
> if __name__ == "__main__":
> import time
> import sys
>
> i_am_active = False
>
> def f():
> global i_am_active
> i_am_active = True
> try:
> try:
> while True:
> time.sleep(0.01)
> except IOError, ex:
> print "IOError handler"
> except TypeError, ex:
> print "TypeError handler"
> print "ex=", repr(ex)
> typ, val, tb = sys.exc_info()
> print "typ=", repr(typ)
> print "val=", repr(val)
> print "tb=", tb
> finally:
> i_am_active = False
>
> t1 = Thread(target = f)
> t1.start()
> time.sleep(1)
> t1.raise_exc(TypeError("blah blah"))
> while i_am_active:
> time.sleep(0.01)
> print "!! thread terminated"
>
> output:
> =
> TypeError handler
> ex= None
> typ= # should be the type
> val= None # should be the instance
> tb=
> !! thread terminated
>
> if i change:
> t1.raise_exc(TypeError("blah blah"))
>
> to:
> t1.raise_exc(TypeError)
>
> i get:
> =
> TypeError handler
> ex=
> typ=
> val=
> tb=
> !! thread terminated
>
> but then of course i can't pass arguments to the exception
>
>
>
> -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 suppressing exceptions
Armin Rigo wrote: > Hi, > > On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote: >>> On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote: I'm in favour of having this __eq__ just return False. I don't think the warning is necessary, (...) >>> +1 >> Can you explain why you believe that no warning is necessary? > > Ah... mostly out of ignorance, I fear. I did not realize there were > strange cases like u"\xff" == "\xff". This is not all that strange. Perhaps this example looks closer to life ;-) if u'D\xfcsseldorf' != 'D\xfcsseldorf': move_to_Cologne() Now, we wouldn't want that to go through without a warning, do we... ;-) [Background: there's a bit of rivalry between those two cities; see e.g. see http://en.wikipedia.org/wiki/D%C3%BCsseldorf] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 11 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] SyntaxError: can't assign to function call
Guido van Rossum wrote: > On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote: >> It makes just as much sense as assigning to an array access, and the >> semantics would be pretty similar. > > No. Array references (x[i]) and attribute references (x.a) represent > "locations". Function calls represent values. This is no different > than the distinction between lvalues and rvalues in C. > Except this syntax is valid in c++ where X() is a constructor call: X(whatever) += 2; is (or can be) valid c++ ___ 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] __index__ clipping
Travis E. Oliphant wrote: > Here is my C-API proposal > > 1) PyIndex_Check(obj) > >Similar to PyIter_Check(obj) as it just checks for whether or not the > object can call nb_index. Actually implemented as a macro. > > 2) PyObject* PyNumber_Index(obj) > >Simple interface around nb_index that calls it if possible and returns >TypeError if not (or if the result does not end up in an exact >int-or-long > > 3) Py_ssize_t PyNumber_AsSsize_t(obj, err) > > This converts the object to a Py_ssize_t by using the nb_index call > if possible. The err argument is a Python error object and specifies > what error should be raised should the conversion from Int-or-Long to > Py_ssize_t cause Overflow. > > If err is NULL, then no error will be raised and the result will be > clipped. Other-wise the corresponding error will be set. Internally > PyExc_IndexError and PyExc_OverflowError will be the errors used. > This proposal is implemented as patch 1538606 http://sourceforge.net/tracker/index.php?func=detail&aid=1538606&group_id=5470&atid=305470 -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] __index__ clipping
Travis E. Oliphant wrote: > Travis E. Oliphant wrote: >> Here is my C-API proposal >> >> 1) PyIndex_Check(obj) >> >>Similar to PyIter_Check(obj) as it just checks for whether or not the >> object can call nb_index. Actually implemented as a macro. >> >> 2) PyObject* PyNumber_Index(obj) >> >>Simple interface around nb_index that calls it if possible and returns >>TypeError if not (or if the result does not end up in an exact >>int-or-long >> >> 3) Py_ssize_t PyNumber_AsSsize_t(obj, err) >> >> This converts the object to a Py_ssize_t by using the nb_index call >> if possible. The err argument is a Python error object and specifies >> what error should be raised should the conversion from Int-or-Long to >> Py_ssize_t cause Overflow. >> >> If err is NULL, then no error will be raised and the result will be >> clipped. Other-wise the corresponding error will be set. Internally >> PyExc_IndexError and PyExc_OverflowError will be the errors used. >> > > This proposal is implemented as patch 1538606 > http://sourceforge.net/tracker/index.php?func=detail&aid=1538606&group_id=5470&atid=305470 This interface is a lot simpler to explain and use than the one in my patch, and more in tune with the rest of the C API. I had a minor documentation suggestion which I put on the tracker item, but other than that +1 on using Travis's patch instead of mine (I've already rejected my own tracker item). 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
Re: [Python-Dev] PyThreadState_SetAsyncExc bug?
[tomer filiba]
> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.
> if i raise an instance, sys.exc_info() confuses the exception value for
> the exception type, and the exception value is set None. if i raise the
> type itself, the interpreter creates an instance internally, but then i can't
> pass arguments to the exception.
That appears to be the way it was designed; i.e., AFAICT, it's working
as intended. This follows from the code in ceval.c that raises the
exception:
if (tstate->async_exc != NULL) {
x = tstate->async_exc;
tstate->async_exc = NULL;
PyErr_SetNone(x);
Py_DECREF(x);
why = WHY_EXCEPTION;
goto on_error;
}
PyErr_SetNone(x) there gives no possibility that setting an /instance/
could work as you hope -- `x` has to be an exception type, and
tstate->async_exc is simply the `exc` argument that was passed to
PyThreadState_SetAsyncExc().
___
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] PyThreadState_SetAsyncExc bug?
so it should be fixed, or at least checked for conformness by the code.-tomerOn 8/11/06, Tim Peters <
[EMAIL PROTECTED]> wrote:[tomer filiba]> while working on a library for raising exceptions in the context
> of another thread, i've come across a bug in PyThreadState_SetAsyncExc.> if i raise an instance, sys.exc_info() confuses the exception value for> the exception type, and the exception value is set None. if i raise the
> type itself, the interpreter creates an instance internally, but then i can't> pass arguments to the exception.That appears to be the way it was designed; i.e., AFAICT, it's workingas intended. This follows from the code in
ceval.c that raises theexception:if (tstate->async_exc != NULL) {x = tstate->async_exc;tstate->async_exc = NULL;
PyErr_SetNone(x);Py_DECREF(x);why = WHY_EXCEPTION;goto on_error;
}PyErr_SetNone(x) there gives no possibility that setting an /instance/could work as you hope -- `x` has to be an exception type, andtstate->async_exc is simply the `exc` argument that was passed to
PyThreadState_SetAsyncExc().
___
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 suppressing exceptions
Guido writes: > Alas, I have no idea what it does. Can you come up with an example > that doesn't require enums and localization? Sorry. Here's the short version: Fact 1: Sometimes people create objects that raise exceptions when compared for equality. Maybe it's a bad idea to do this, and objects should never raise exceptions when compared except to signal internal inconsistancy -- but the practice is common enough to show up in a 5-star recipe for enums in the Cookbook. Fact 2: Unrelated objects are often put in dictionarys together. I used a "localization dictionary" as an example. I feel this is a legitimate practice. If dictionarys stop suppressing exceptions raised by equality tests then those two facts aren't compatible. Programs that used to work fine will break with 2.4. I'm OK with your proposed solution (fix the case of str-unicode but let everyone else using objects that raise exceptions suffer), but I think it would be more friendly to use warnings for now and exceptions after another full release cycle. The warnings should solve the underlying issue (hard-to-debug problems). -- Michael Chermside ___ 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 suppressing exceptions
On 8/11/06, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote: > > > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote: > > > > I'm in favour of having this __eq__ just return False. I don't think > > > > the warning is necessary, (...) > > > > > > +1 > > > > Can you explain why you believe that no warning is necessary? > > Ah... mostly out of ignorance, I fear. I did not realize there were > strange cases like u"\xff" == "\xff". I will leave this to more > unicode-minded people to decide, but I'm still definitely of the idea > that the __eq__ should not raise an exception. Me too, and that's what we'll do in py3k. But in 2.5, we're bound by the decisions we made in 1999-2000 about unicode. (Unless Martin has a convincing reason not to have a warning?) Marc-Andre, how's the patch coming along? -- --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] __index__ clipping
OK, I'll withdraw from this discussion again. Thanks all! On 8/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Travis E. Oliphant wrote: > > Travis E. Oliphant wrote: > >> Here is my C-API proposal > >> > >> 1) PyIndex_Check(obj) > >> > >>Similar to PyIter_Check(obj) as it just checks for whether or not the > >> object can call nb_index. Actually implemented as a macro. > >> > >> 2) PyObject* PyNumber_Index(obj) > >> > >>Simple interface around nb_index that calls it if possible and returns > >>TypeError if not (or if the result does not end up in an exact > >>int-or-long > >> > >> 3) Py_ssize_t PyNumber_AsSsize_t(obj, err) > >> > >> This converts the object to a Py_ssize_t by using the nb_index call > >> if possible. The err argument is a Python error object and specifies > >> what error should be raised should the conversion from Int-or-Long to > >> Py_ssize_t cause Overflow. > >> > >> If err is NULL, then no error will be raised and the result will be > >> clipped. Other-wise the corresponding error will be set. Internally > >> PyExc_IndexError and PyExc_OverflowError will be the errors used. > >> > > > > This proposal is implemented as patch 1538606 > > http://sourceforge.net/tracker/index.php?func=detail&aid=1538606&group_id=5470&atid=305470 > > This interface is a lot simpler to explain and use than the one in my patch, > and more in tune with the rest of the C API. > > I had a minor documentation suggestion which I put on the tracker item, but > other than that +1 on using Travis's patch instead of mine (I've already > rejected my own tracker item). > > 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] SyntaxError: can't assign to function call
On 8/11/06, Neal Becker <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote: > >> It makes just as much sense as assigning to an array access, and the > >> semantics would be pretty similar. > > > > No. Array references (x[i]) and attribute references (x.a) represent > > "locations". Function calls represent values. This is no different > > than the distinction between lvalues and rvalues in C. > > > > Except this syntax is valid in c++ where X() is a constructor call: > > X(whatever) += 2; is (or can be) valid c++ As I said before, C++ has a fundamentally different concept of what assignment means; it is of no use for understanding Python's assignment. Actually it is a big hindrance knowing about C++ assignment because it's difficult to explain to C++ users why Python can't and won't allow assignment to be overloaded. -- --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
[Python-Dev] Elementtree and Namespaces in 2.5
I'm happy to see Elementtree being considered for inclusion with 2.5. However, before committing to this decision, there's an issue regarding it's namespace parsing that should be addressed. Although Elmenttree is in most respects an excellent XML parser, a huge gotcha that often makes Elementtree unsuitable for many applications lies in the way it arbitrarily renames namespaces. For example, given: http://www.xml.com/books"; xmlns:h="http://www.w3.org/HTML/1998/html4";> Book Review XML: A Primer AuthorPrice PagesDate Simon St. Laurent 31.98 352 1998/01 Elementtree would rewrite this as: http://www.w3.org/HTML/1998/html4";> Book Review http://www.xml.com/books";> XML: A Primer AuthorPrice PagesDate Simon St. Laurent 31.98 352 1998/01 There's been some discussion in comp.lang.python about this functionality (http://groups.google.com/group/comp.lang.python/browse_thread/thread/31b2e9f4a8f7338c/363f46513fb8de04?&rnum=3&hl=en) and while most users and the w3 spec (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting) agree this feature is actually a bug, Fredrik Lundh has refused to fix this problem. Of course, this is his right. Unfortunately, Elementtree's design makes a work-around rather awkward. Therefore, we might want to rethink inclusion of Elementtree in the stdlib, or at least patch the stdlib's version of Elementtree to produce an output more in line with the w3 standard. Sincerely, Chris Spencer ___ 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 suppressing exceptions
Guido van Rossum wrote: > Marc-Andre, how's the patch coming along? I'm working on it. Since we only want equal compares to generate the warning, I have to add a rich compare function to Unicode objects. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 11 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Elementtree and Namespaces in 2.5
Chris Spencer writes: > there's an issue > regarding [ElementTree's] namespace parsing that should be addressed. [... it performs namespace rewriting ...] > while most users and the w3 spec > (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting) > agree this feature is actually a bug, Fredrik Lundh has refused to fix > this problem. Of course, this is his right. Unfortunately, > Elementtree's design makes a work-around rather awkward. Therefore, we > might want to rethink inclusion of Elementtree in the stdlib, or at > least patch the stdlib's version of Elementtree to produce an output > more in line with the w3 standard. The good news for you is that: (1) Including ElementTree in the stdlib does not (immediately) take away from any of the other XML librarys out there. (2) Including ElementTree in the stdlib *increases* the chance that requests from users will lead to a change in the library. (3) Changing ElementTree to preserve namespace prefixes would be backward compatible with a version that didn't preserve it, so nothing happening now forecloses fixing this in future releases. Now, in my opinion, the W3 flubbed badly in the way they designed namespaces, prefixes, and allowing namespace prefixes to appear within element content and attributes. Creating a universal namespace with local aliases to prevent name clashes is nice, making the local aliases significant so that we haven't prevented name clashes after all but have merely introduced vast complexity (and *encouraged* clashes by shortening the names) is... not so nice. But that's beside the point. Even if we presume 100% agreement on the need to change ElementTree, the best thing to do is still to release ElementTree in the stdlib exactly as it is in 2.5 and change it for 2.6. -- Michael Chermside ___ 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] openSSL and windows binaries - license
Greg Ewing schrieb: > That can't be right, because it would mean that > anyone who runs a program that contains a > patented algorithm, even one bought or otherwise > obtained from someone else, would need to > individually negotiate a licence with the > patent owner. That clearly doesn't happen. No, that isn't necessary. If you buy a patented screwdriver, and the maker of the screwdriver isn't the patent owner but has an appropriate license, you don't need to negotiate with the patent owner to use the screwdriver. Same with software patents: whoever sold you the software should have negotiated a transferable license that allows use of the algorithm in this software; transfer of the license would likely be bound to usage within this product. So this doesn't get completely OT: The IDEA algorithm is licensed free of charge for non-commercial use (I believe to anybody, ask the patent owner if uncertain); commercial users need to buy a license (I would expect that transferable licenses are also available for sale). 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] Dict suppressing exceptions
Guido van Rossum schrieb: > Me too, and that's what we'll do in py3k. But in 2.5, we're bound by > the decisions we made in 1999-2000 about unicode. (Unless Martin has a > convincing reason not to have a warning?) Only the general anti-warning argument: it's not the developer which will see the warning, but the end user. In this case, they might easily get hundreds of warning in a short time, and these fill their Apache log files. They complain about Python eating their disk space. 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
[Python-Dev] Errors after running make test
There are errors now after the testsuite has finished. Taken from the very end of the amd64 test log (for example). http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/1403/step-test/0 [...] 293 tests OK. 26 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_curses test_dl test_gl test_imageop test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 1351, in shutdown h.flush() File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/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 "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 1351, in shutdown h.flush() File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 731, in flush self.stream.flush() ValueError: I/O operation on closed file [449107 refs] program finished with exit code 0 ___ 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 suppressing exceptions
Michael Chermside schrieb: > I don't *strongly* object to this consensus, but if you haven't > glanced at my original example, take a look - it might convince you. > The proposed solution will not help with my example. I ignored your example the first time because it was too complicated to understand. Now I looked at it, and think that the recipe is broken. It should add an __eq__ method which is def __eq__(self, other): return type(self) is type(other) \ and self.EnumType is other.EnumType \ and self.__value==other.__value) 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] Elementtree and Namespaces in 2.5
Chris S schrieb: > I'm happy to see Elementtree being considered for inclusion with 2.5. > However, before committing to this decision, there's an issue > regarding it's namespace parsing that should be addressed. Although > Elmenttree is in most respects an excellent XML parser, a huge gotcha > that often makes Elementtree unsuitable for many applications lies in > the way it arbitrarily renames namespaces. Terminology alert: it doesn't rename namespaces. It renames namespace prefixes. The namespaces stay unmodified. > functionality > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/31b2e9f4a8f7338c/363f46513fb8de04?&rnum=3&hl=en) > and while most users and the w3 spec > (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting) > agree this feature is actually a bug, Fredrik Lundh has refused to fix > this problem. You are misunderstanding. The "w3 spec" does not say it is a bug; you are looking at the wrong spec. The right spec to look at is http://www.w3.org/TR/REC-xml-names/ You are looking at a resolution of an issue in the spec of Canonical XML (i.e. not even the actual spec, just the resolution of an issue). Now, C14N specifies that the canonical form of an XML document has the same namespace prefixes as the original document. So ElementTree does not implement C14N for that reason, but I guess there are many more reasons why ElementTree is not a C14N implementation. For example, it puts the attributes before the namespace attributes, when C14N says it should be the other way 'round. > Of course, this is his right. Unfortunately, > Elementtree's design makes a work-around rather awkward. Therefore, we > might want to rethink inclusion of Elementtree in the stdlib That is not enough reason. Yes, it makes certain applications impossible, e.g. when namespace prefixes are inside attribute values. It just means you can't use it for that application, then. XML has many other applications, and so does ElementTree. > or at > least patch the stdlib's version of Elementtree to produce an output > more in line with the w3 standard. That is out of the question. It was agreed that ElementTree is added to the standard library only if Fredrik Lundh gets veto rights on all changes. 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] SyntaxError: can't assign to function call
Michael Urman schrieb: > On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote: >> The question doesn't make sense: in Python, you assign to a name, >> an attribute or a subscript, and that's it. > > Just to play devil's advocate here, why not to a function call via a > new __setcall__? Just try specifying this one day. I'm sure a dozen readers of the list will rip apart the first specification you make as underspecified or unimplementable (hint: what is the precise syntax for the left-hand side? how to parse it? what is the precise parameter list?) 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] SyntaxError: can't assign to function call
Neal Becker schrieb:
>> No. Array references (x[i]) and attribute references (x.a) represent
>> "locations". Function calls represent values. This is no different
>> than the distinction between lvalues and rvalues in C.
>>
>
> Except this syntax is valid in c++ where X() is a constructor call:
>
> X(whatever) += 2; is (or can be) valid c++
That's actually the less-interesting case. You would have to overload
+= to make it work, right?
The more interesting case is when X is a function that returns a
reference:
int& X(int);
void foo(){
X(1) += 2;
}
int bar, foobar;
int& X(int t){
if(t) return bar;
return foobar;
}
Here, which variable gets incremented depends on whether the t
argument is true; no overloading of assignment comes into play.
The trick is that C++ has functions that *return* lvalues;
neither C nor Python has such things.
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] Unicode Data in Python2.5 is missing a ucd_4_1_0 object
Armin Ronacher schrieb: > Right, I didn't know that. From that old bug report it sounded like a > programmer > should be able to select a specific UCD version. Well, my comment was that _IDNA_ needs to access _3.2_. This isn't as general as "any application needs to access any version". We likely drop 3.2 when IDNA stops using it, and we likely drop 4.1 when moving to 5.0. Of course, now the infrastructure is there for keeping old versions efficiently, so if compelling reasons are brought forward to keep an old version, it would be possible. 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] SyntaxError: can't assign to function call
At 09:40 PM 8/11/2006 +0200, Martin v. Löwis wrote: >Michael Urman schrieb: > > On 8/9/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > >> The question doesn't make sense: in Python, you assign to a name, > >> an attribute or a subscript, and that's it. > > > > Just to play devil's advocate here, why not to a function call via a > > new __setcall__? > >Just try specifying this one day. I'm sure a dozen readers of the list >will rip apart the first specification you make as underspecified or >unimplementable (hint: what is the precise syntax for the left-hand >side? how to parse it? what is the precise parameter list?) Actually, this isn't as hard as you're implying. In at least the "compiler.ast" package, such an operation would be represented as a CallFunc node as the child of an Assign node. Wrapping the call node's main child expression in a Getattr for __setcall__ would then effect the relatively simple AST transformation required. This is because Python's grammar *already* allows arbitrary LHS expressions; it's just that the compiler rejects LHS nodes that aren't a Getattr, Subscript, or Name. (The above should not be confused with advocacy for the feature; I'm just pointing out that specifying it -- or even implementing it -- isn't that complicated.) ___ 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] SyntaxError: can't assign to function call
Phillip J. Eby schrieb: > Actually, this isn't as hard as you're implying. In at least the > "compiler.ast" package, such an operation would be represented as a > CallFunc node as the child of an Assign node. Wrapping the call node's > main child expression in a Getattr for __setcall__ would then effect the > relatively simple AST transformation required. Well, you are experienced with that stuff, and would be one of the people who could rip apart a specification attempt. There are just many details to it, for example, what is the evaluation order when I write f(g()) = h() Or what about chained assignments a = b() = c() Is the return value of __setcall__ used or not? What about augmented assignments? Any specific question that somebody asks gets an easy (although perhaps arbitrary) answer. Still, I guess many people would be surprised how large the specification of a seemingly simple feature will be. 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
[Python-Dev] Dict suppressing exceptions
Martin v. Löwis wrote: > Now I looked at it, and think that the recipe is broken. It should > add an __eq__ method which is > def __eq__(self, other): > return type(self) is type(other) \ > and self.EnumType is other.EnumType \ > and self.__value==other.__value) Absolutely. But the point is that there are a lot of these broken objects out there; this one was on a 5-star recipe that has been around for a while, and still no one caught it. That suggests the bug could reasonably be in any 3rd-party library. The existence of a (common) bug in someone else's code shouldn't keep me from using a dictionary of objects. hash was just changed to support the common use of id, even though some people argued it was *really* a bug in the classes themselves. This is a similar situation. -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] Dict suppressing exceptions
Martin v. Löwis writes: > Now I looked at it, and think that the recipe is broken. Not broken, but perhaps wrongheaded. The recipe went out of its way to ensure that it would raise an exception of enum values from different enumerations were compared. There's nothing out there saying that this is a bad thing to do. I propose that we institute a new policy. The policy should state: __eq__ methods should always return True or False. They should only raise an exception if there is some internal error within one of the objects being compared -- they should never raise an exception because the other object is of an unexpected type. On the other hand, __lt__, __gt__ and friends SHOULD raise an exception when the object being compared is of some type for which the ordering does not make sense (e.g.: unicode vs byte-string or complex vs anything). I think we should note this policy someplace official -- perhaps in the Language Reference where __eq__ and __lt__ are defined. But I do not think that these changes should be made until Py3K. What do others think? Is this the "right" approach? -- Michael Chermside ___ 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 suppressing exceptions
M.-A. Lemburg wrote: > Guido van Rossum wrote: >> Marc-Andre, how's the patch coming along? > > I'm working on it. > > Since we only want equal compares to generate the warning, > I have to add a rich compare function to Unicode objects. Here's an initial version: http://sourceforge.net/tracker/index.php?func=detail&aid=1538956&group_id=5470&atid=305470 The title of the patch is slightly incorrect - SF doesn't allow more descriptive titles... :-( -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 11 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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 suppressing exceptions
Michael Chermside schrieb: > Not broken, but perhaps wrongheaded. The recipe went out of its way > to ensure that it would raise an exception of enum values from different > enumerations were compared. There's nothing out there saying that this > is a bad thing to do. And it's actually fine for three-way compare: different enums don't naturally arrange. > I propose that we institute a new policy. The policy should state: > >__eq__ methods should always return True or False. They should >only raise an exception if there is some internal error within >one of the objects being compared -- they should never raise >an exception because the other object is of an unexpected type. That policy is currently difficult to implement, but reasonable (difficult because it is quite some code to write). >On the other hand, __lt__, __gt__ and friends SHOULD raise an >exception when the object being compared is of some type for >which the ordering does not make sense (e.g.: unicode vs >byte-string or complex vs anything). Right; same for three-way compare. > What do others think? Is this the "right" approach? For the moment, the first section gets augmented by "issue a warning if you think the user is comparing things incorrectly". 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
[Python-Dev] What is the status of file.readinto?
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? ___ 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] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod
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/archive%40mail-archive.com
Re: [Python-Dev] Dict suppressing exceptions
On 8/11/06, Michael Chermside <[EMAIL PROTECTED]> wrote: > Martin v. Löwis writes: > > Now I looked at it, and think that the recipe is broken. > > Not broken, but perhaps wrongheaded. The recipe went out of its way > to ensure that it would raise an exception of enum values from different > enumerations were compared. There's nothing out there saying that this > is a bad thing to do. Except a little voice in my head. :-) > I propose that we institute a new policy. The policy should state: > > __eq__ methods should always return True or False. They should > only raise an exception if there is some internal error within > one of the objects being compared -- they should never raise > an exception because the other object is of an unexpected type. That's pretty much what I want to do in py3k. There, ordering will raise a TypeError by default, but == compares object identity by default, and it's strongly recommended to return False for any unrecognized type. I want the recommendation to be a *little* more relaxed than your proposal; IMO it's fine to raise an exception when your __eq__ implementation is incomplete, i.e. you haven't thought enough about how your class should compare to other classes. The "don't silence exceptions" rule will then cause loud complaints when your class gets compared to something it didn't expect being compared to, signalling that you have more work to do. (And yes, this can cause sleeper bombs when you use these objects as dict keys together with types that it doesn't understand, and the bomb will go off if there's a hash collision; but I've got fairly controlled situations in mind, not robust libraries or frameworks.) > On the other hand, __lt__, __gt__ and friends SHOULD raise an > exception when the object being compared is of some type for > which the ordering does not make sense (e.g.: unicode vs > byte-string or complex vs anything). Yes, that's the py3k rule. > I think we should note this policy someplace official -- perhaps > in the Language Reference where __eq__ and __lt__ are defined. But > I do not think that these changes should be made until Py3K. Fine to update the docs now. > What do others think? Is this the "right" approach? Yes. -- --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] Dict suppressing exceptions
On 8/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Michael Chermside schrieb: > > I propose that we institute a new policy. The policy should state: > > > >__eq__ methods should always return True or False. They should > >only raise an exception if there is some internal error within > >one of the objects being compared -- they should never raise > >an exception because the other object is of an unexpected type. > > That policy is currently difficult to implement, but reasonable > (difficult because it is quite some code to write). Why? Are you thinking of the standard library, or of an end user's __eq__ method? Returning False from your __eq__ if other's type is unexpected doesn't seem a lot of code. Or am I misunderstanding something? -- --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] Dict suppressing exceptions
Guido van Rossum schrieb: >> >__eq__ methods should always return True or False. They should >> >only raise an exception if there is some internal error within >> >one of the objects being compared -- they should never raise >> >an exception because the other object is of an unexpected type. >> >> That policy is currently difficult to implement, but reasonable >> (difficult because it is quite some code to write). > > Why? Are you thinking of the standard library, or of an end user's > __eq__ method? Returning False from your __eq__ if other's type is > unexpected doesn't seem a lot of code. Or am I misunderstanding > something? It seemed like a lot of code to me: In the specific enum example, I first wrote def __eq__(self, other): return self.EnumType is other.EnumType \ and self.__value==other.__value So this was wrong, as it did not take into account 'other' being something completely different, and I wrote def __eq__(self, other): return type(self) is type(other) \ and self.EnumType is other.EnumType \ and self.__value==other.__value Having two additional continuation lines seems quite difficult to me, yet a version that breaks the expression into multiple statements is even longer def __eq__(self, other): if type(self) is not type(other): return False if self.EnumType is not other.EnumType: return False return self.__value==other.__value Compare this to the current two-line __cmp__ implementation: def __cmp__(self, other): assert self.Enumtype is other.EnumType return cmp(self.__value, other.__value) This covers all comparisons just fine in two lines of method body; to implement the __eq__ policy, you need another 6 lines. For consistency, you should also implement __ne__, probably as def __ne__(self, other): return not self.__eq__(other) I expect many people get this wrong, for example http://pyref.infogami.com/__eq__ UserList.py Also, there is confusion as to whether NotImplemented should ever be returned in these. decimal.py believes it does (for different types), sets.py believes it doesn't. 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] Dict suppressing exceptions
Jim Jewett schrieb: > hash was just changed to support the common use of id, even though > some people argued it was *really* a bug in the classes themselves. > This is a similar situation. Similar still different. In the case of __hash__ returning id(), it is very clear what the intention of the program is, and it is implementable to give the program its intended meaning (i.e. use the object address as the source of the hash value). In this case, it is not clear what the intention of the program is. __cmp__ raises an exception, and you say the intention is that this exception should be discarded? Errors should never pass silently, unless explicitly silenced. Some users will find "Oops, I didn't know all these years I had this error there", and correct their code. Some will say "why did they break my program", and correct their code - the corrected code will run just fine on older versions of Python as well. 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] 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 [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
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
