[issue32081] ipaddress should support fast IP lookups
New submission from Attila Nagy <nagy.att...@gmail.com>: It would be nice if ipaddress could support fast IP lookups, like this: https://github.com/jsommers/pytricia -- components: Library (Lib) messages: 306535 nosy: Attila Nagy priority: normal severity: normal status: open title: ipaddress should support fast IP lookups type: enhancement ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
Attila Nagy added the comment: I don't think this should be done by default as it will break people's expectations and, perhaps worse, compatibility. I won't mind another thread naming API, if somebody does this. :) But personally I expected python to name my threads (and if the OS supports it, on that level), I was actually surprised to see that it doesn't, mostly because I remembered a patch for FreeBSD, which did this years ago, so I thought it has been merged into mainline since then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
New submission from Attila Nagy: Python class Thread has a name argument, which sets the name of the given thread. This name is used only internally, while there is a possibility to set this on an OS-level. Related discussion: http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-in-pthreads-linux #include pthread.h int pthread_setname_np(pthread_t thread, const char *name); // FreeBSD OpenBSD: function name is slightly different void pthread_set_name_np(pthread_t tid, const char *name); // Mac OS X: it only seems applicable to the current thread (no thread ID) int pthread_setname_np(const char*); It would be very useful if Python set the name parameter with the above pthread calls, so the user/developer could see which threads do what in ps or top. -- components: Library (Lib) messages: 166890 nosy: bra priority: normal severity: normal status: open title: Python should support naming threads type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8792] xmlrpclib compatibility issues with Apache XML-RPC library
New submission from Attila Nagy b...@fsn.hu:
When talking to an Apache XML-RPC library based application via python 2.6.5
xmlrpclib, I get this exception:
Traceback (most recent call last):
File prb.py, line 4, in module
proxy.catv.getEndpointIdByIp('1.1.1.1')
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 1199, in __call__
return self.__send(self.__name, args)
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 1491, in __request
verbose=self.__verbose
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 1253, in request
return self._parse_response(h.getfile(), sock)
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 1389, in _parse_response
p.feed(response)
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 601, in feed
self._parser.Parse(data, 0)
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 868, in end
return f(self, join(self._data, ))
File /tmp/Python-2.6.5/Lib/xmlrpclib.py, line 935, in end_struct
dict[_stringify(items[i])] = items[i+1]
IndexError: list index out of range
The exception is caused by the XML response, which includes a value with
ex:i8 type. According to this: http://ws.apache.org/xmlrpc/types.html, there
are a lot more types, which are not understood by python's xmlrpclib.
It's easy to fix the above by adding ex:i8 to the list of end_int dispatcher:
def end_int(self, data):
self.append(int(data))
self._value = 0
dispatch[i4] = end_int
dispatch[i8] = end_int
dispatch[ex:i8] = end_int
dispatch[int] = end_int
This makes the error disappear (and the program to work).
Of course, it would be nice to support all other types as well (in both
directions).
--
components: XML
messages: 106322
nosy: bra
priority: normal
severity: normal
status: open
title: xmlrpclib compatibility issues with Apache XML-RPC library
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8792
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8210] rev 78820 causes problems on Solaris (Python 2.6)
New submission from Attila Nagy nagy.att...@yahoo.com: The check-in http://svn.python.org/view?view=revrevision=78820 causes problems on Solaris (SXCE 125, ksh, Studio 12). configure output: [...] checking for --with-pydebug... no ./configure: test: unknown operator == test on Solaris does not accept ==. = works okay. -- components: Build messages: 101577 nosy: attila severity: normal status: open title: rev 78820 causes problems on Solaris (Python 2.6) versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8210] rev 78820 causes problems on Solaris (Python 2.6)
Attila Nagy nagy.att...@yahoo.com added the comment: Thank you, that was fast! :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
