[issue43979] Simplify urllib.parse_qsl
Christoph Zwerschke added the comment: I don't mind if you reopen your PR. But thanks for asking. -- ___ Python tracker <https://bugs.python.org/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43979] Simplify urllib.parse_qsl
Christoph Zwerschke added the comment: I saw you submitted a PR already which looks good to me. -- ___ Python tracker <https://bugs.python.org/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43979] Simplify urllib.parse_qsl
New submission from Christoph Zwerschke : Just noticed the following code in urrlib.parse_qsl: pairs = [s1 for s1 in qs.split(separator)] for name_value in pairs: ... see https://github.com/python/cpython/blob/088a15c49d99ecb4c3bef93f8f40dd513c6cae3b/Lib/urllib/parse.py#L755 This looks like an unnecessary list comprehension to me, probably a relic of earlier code that used a nested list comprehension for splitting with two different separators. Can't we just do this instead now, which is faster and shorter? for name_value qs.split(separator): I can provide a PR if wanted. -- components: Library (Lib) messages: 392345 nosy: cito priority: normal severity: normal status: open title: Simplify urllib.parse_qsl type: performance versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Christoph Zwerschke added the comment: Just created a test case for this problem after a pentest provoked this error on one of my web apps. Then I found this bug report which already has a similar test case attached. The problem is that read_binary() as the name says reads binary data, but then writes it to a file which may or may not be binary, depending on whether self._binary_file is set, which depends on whether a filename was set via the content-disposition header. Jakub's patch looks good and works for me. Please merge this! -- ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1375011] http.cookies, Cookie.py: Improper handling of duplicate cookies
Christoph Zwerschke added the comment: This patch should really be included. As carl already mentioned, the relevant spec is RFC 6265, see section 5.4.2: "The user agent SHOULD sort the cookie-list in the following order: Cookies with longer paths are listed before cookies with shorter paths. Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times." Currently, if the cookies are loaded with cookies.load(env['HTTP_COOKIE']) as most web frameworks do, then the cookies will be populated with the least specific or oldest values if there are duplicates. This is really bad. -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue1375011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18319] gettext() cannot find translations with plural forms
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue18319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Christoph Zwerschke added the comment: Had the same problem for years and wondered why nobody else complained. Still reproducable with Win 10 Pro 2004, Python 3.8, cp1252 locale. Deleting hh.dat did not solve the problem for me. -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38531] argparse action "extend" not documented as new
New submission from Christoph Zwerschke : A new action "extend" has been added to argparse in https://github.com/python/cpython/commit/aa32a7e1116f7aaaef9fec453db910e90ab7b101 The documentation should specify that this is new in Python 3.8 addition. I wondered why it didn't work in Python 3.7. -- assignee: docs@python components: Documentation messages: 354966 nosy: cito, docs@python priority: normal severity: normal status: open title: argparse action "extend" not documented as new type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Christoph Zwerschke added the comment: This also happens when sending POST requests with JSON payload from a browser with XMLHttpRequest to a Python 3.7 backend using FieldStorage. It seems XMLHttpRequest adds the content length automatically. -- ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37110] Clarify hashability of custom class instances
Christoph Zwerschke added the comment: My point was that it's not immediately obvious what "by default" means and that hashability is not only affected by the __hash__ method but also by __eq__. But I agree, you can argue that "by default" already includes not adding any special methods like __eq__ and the glossary should not become too verbose. (I remember these words from Donald Knuth in one of his books: "In the interest of conciseness, you need to indulge in simplifications that are really little lies; these should be overlooked.") -- ___ Python tracker <https://bugs.python.org/issue37110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37110] Clarify hashability of custom class instances
New submission from Christoph Zwerschke : The Python documentation says about hashability in the glossary (https://docs.python.org/3/glossary.html#term-hashable): "Objects which are instances of user-defined classes are hashable by default." This is not quite true. Objects of a user-defined class with an __eq__ method are not hashable. Maybe it would be better to make this more explicit: "Objects which are instances of user_defined classes without custom __eq__ and __hash__ methods are hashable by default." -- assignee: docs@python components: Documentation messages: 344042 nosy: cito, docs@python priority: normal severity: normal status: open title: Clarify hashability of custom class instances type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34730] aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()
Change by Christoph Zwerschke : -- nosy: +cito ___ Python tracker <https://bugs.python.org/issue34730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
GraphQL-core-next 1.0.0 released
Hi all, I'm glad to announce that the first public release 1.0.0 of Graphql-core-next is now available on PyPI. Graphql-core-next is a port of GraphQL.js, the reference implementation for the GraphQL query language written in JavaScript, to modern Python. GraphQL-core-next 1.0.0 is up to date with GraphQL.js 14.0.0. This library may become a successor to the existing GraphQL-core library by Syrus Akbary which still supports legacy Python versions. Please have a look and give me some feedback. Source: https://github.com/graphql-python/graphql-core-next/ Docs: https://graphql-core-next.readthedocs.io/ PyPI: https://pypi.org/project/GraphQL-core-next/ Christoph Zwerschke https://github.com/Cito -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue31140] Insufficient error message with incorrect formated string literal
Christoph Zwerschke <c...@online.de> added the comment:
I can confirm that the problem still exists in Python 3.6.4 and 3.7.0a4.
Here is another way to demonstrate it:
Create the following file test.py:
# test
hello = f"{world)}"
Note that there is a syntax error in the f-string in line 2 which has a closing
parentheses, but no opening one.
Import this from Python 3.6.4 or 3.7.0a4:
>>> import test
Traceback (most recent call last):
File "", line 1, in
File "", line 1
(world))
^
SyntaxError: unexpected EOF while parsing
The problem here is that the error message does not contain the name of the
erroneous file (test.py), points to a wrong line (line 1 instead of line 2),
and also shows parentheses instead of braces around the word "world", which are
not there in the original code. This can make it hard to locate such errors.
Note that when there are other kinds of errors in the f-string, or other kinds
of "unexpected EOF" in the imported file, the errorenous file is usually
reported correctly in the error message. Only certain kinds of syntax errors in
f-strings seem to be problematic.
--
nosy: +cito
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1697943] msgfmt cannot cope with BOM
Christoph Zwerschke added the comment: > Corresponding GNU gettext issue [1] was closed as "Not a Bug". Though I think the rationale given there pointing to RFC3629 section 6 is wrong, since that section explicitly refers to Internet protocols, but PO files are not an Internet protocol. Anyway, if silently ignoring BOMs is considered a bad idea, then at least there should be a more helpful error message. Because the BOM is invisible, users - who may not even be aware that something like a BOM exist or that their editor saves files with BOM - may be frustrated about the current error message because they don't see any invalid character when they open the PO file in their editor. A more explicit error message like "PO files should not be saved with a byte order mark" might point users in the right direction. After all, these tools are supposed to be used directly by human beings on the command line. Who said that command line tools must not be user friendly? -- status: pending -> open versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1697943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings
Christoph Zwerschke added the comment: After this patch, some of the values in mimetypes.types_map now appear as unicode instead of str in Python 2.7.7 under Windows. For compatibility and consistency reasons, I think this should be fixed so that all values are returned as str again under Python 2.7. See https://groups.google.com/forum/#!topic/pylons-devel/bq8XiKlGgv0 for a real world issue which I think is caused by this bugfix. -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17326] Windows build docs still referring to VS 2008 in 3.3
New submission from Christoph Zwerschke: The first paragraph in PCbuild/readme.txt of Python 3.3 still talks about Visual C++ 2008 Express and Visual Studio 2008. It says that VS 2008 is required at the very least (which may be still true, I'm not sure), but then it also says the official Python releases are built with this [i.e. the 2008] version of VS, while it seems they have been built with VS 2010 in reality (as the title is also indicating). -- assignee: docs@python components: Documentation messages: 183259 nosy: cito, docs@python priority: normal severity: normal status: open title: Windows build docs still referring to VS 2008 in 3.3 type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Webware for Python 1.1.1 released
Version 1.1.1 of Webware for Python can now be downloaded at http://downloads.sourceforge.net/webware/Webware-1.1.1.tar.gz. This is a bugfix release with some fixes and small improvements. Webware for Python is a mature and stable web framework that has been around since more than a decade. Version 1.1.1 runs on Python 2.4 to 2.7. You can find more info on the Webware for Python homepage at http://www.webwareforpython.org/ Support is available via the Webware for Python mailing lists at https://sourceforge.net/mail/?group_id=4866 -- Christoph Zwerschke -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: DBUtils 1.1 released
DBUtils 1.1 has been released. DBUtils is a suite of tools providing solid, persistent and pooled connections to a database that can be used in all kinds of multi-threaded environments such as Webware for Python or other web application servers. The suite supports DB-API 2 compliant database interfaces and the classic PyGreSQL interface. The new version is available for download at: * http://www.python.org/pypi/DBUtils/ and * http://www.w4py.org/downloads/DBUtils/ Changes: * http://www.w4py.org/DBUtils/Docs/RelNotes-1.1.html User's Guide available at: * http://www.w4py.org/DBUtils/Docs/UsersGuide.html -- Christoph Zwerschke -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
ANN: Webware for Python 1.1 released
A new version 1.1 of the venerable Webware for Python web framework is now available for download at http://downloads.sourceforge.net/webware/Webware-1.1.tar.gz. This release offers some major new features, e.g. a WSGI adapter, sessions based on shelve or Memcached, MiddleKit supporting SQLite. Webware requires Python 2.4 now. The code base has been cleaned up and modernized very much; all the old cruft that was only there to support older Python versions has been removed. The older Python versions are still supported via the latest bugfix version 1.0.3 of the 1.0 branch which has been released along with the current version 1.1. You can find more info on the Webware for Python homepage at http://www.webwareforpython.org/ Support is available via the Webware for Python mailing lists at https://sourceforge.net/mail/?group_id=4866 -- Christoph Zwerschke -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue7402] reduce() is an anti-example in Idioms and Anti-Idioms
Christoph Zwerschke c...@online.de added the comment: My point was that the passage starts with there are also many useful built-in functions people seem not to be aware of for some reasons and then it looks like the author himself was not aware of sum() for some reason because he gives calculating a sum with reduce() as a classical example. It's very hard to come up with good examples for reduce() and I think in newer Python versions it has been demoted from builtin to functools, so it's not a good example for a useful built-in fuction anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7402] reduce() is an anti-example in Idioms and Anti-Idioms
New submission from Christoph Zwerschke c...@online.de: In the section Using the batteries of the Idioms and Anti-Idioms in Python document (http://docs.python.org/dev/howto/doanddont.html#using-the-batteries), the reduce statement is used for summing up numbers as an example. I think this is rather an anti-example, because Python already has a sum function built-in, i.e. reduce(operator.add, nums)/len(nums) can be written much simpler as sum(nums)/len(nums). -- assignee: georg.brandl components: Documentation messages: 95762 nosy: cito, georg.brandl severity: normal status: open title: reduce() is an anti-example in Idioms and Anti-Idioms versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Changes by Christoph Zwerschke c...@online.de: -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6777] Python 2.6 tutorial still recommends using Exception.message attribute
New submission from Christoph Zwerschke c...@online.de: The Python 2.6.2 tutorial says at the end of secton 8.3 (http://docs.python.org/tutorial/errors.html#handling-exceptions): But use of .args is discouraged. Instead, the preferred use is to pass a single argument to an exception (which can be a tuple if multiple arguments are needed) and have it bound to the message attribute. It seems this is not true any more, the idea has been retracted so that it's now the other way around again: .args can still be used, but .message is deprecated (see http://www.python.org/dev/peps/pep- 0352/#retracted-ideas). The examples classes in section 8.5 of the Tutorial, using the .message attribute should be also adapted because they raise a DeprecationWarning in Python 2.6.2. -- assignee: georg.brandl components: Documentation messages: 91937 nosy: cito, georg.brandl severity: normal status: open title: Python 2.6 tutorial still recommends using Exception.message attribute versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6423] The cgi docs should advertize using in instead of has_key
New submission from Christoph Zwerschke c...@online.de: The cgi.Fieldstorage class supports the __contains__ method since Py 2.2, but the documentation of Py 2.6 still only mentions the old fashioned has_key method. See patch. -- assignee: georg.brandl components: Documentation files: cgi.patch keywords: patch messages: 90158 nosy: cito, georg.brandl severity: normal status: open title: The cgi docs should advertize using in instead of has_key versions: Python 2.6 Added file: http://bugs.python.org/file14456/cgi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Webware for Python 1.0.2 released
Webware for Python 1.0.2 has been released. This is the second bugfix release for Webware for Python release 1.0, mainly fixing some problems and shortcomings of the PSP plug-in. See the WebKit and PSP release notes for details. Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. Check out the Webware for Python home page at http://www.w4py.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
[issue4799] handling inf/nan in '%f'
Christoph Zwerschke c...@online.de added the comment: This is a related problem on Windows: '%g' % 1e400 - '1.#INF' '%.f' % 1e400 -- '1' -- nosy: +cito ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Webware for Python 1.0.1 released
Webware for Python 1.0.1 has been released. This is the first bugfix release for Webware for Python release 1.0, mainly fixing a problem that could appear when communicating with the threaded application server over a network connection. See the WebKit release notes for details. Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. Check out the Webware for Python home page at http://www.w4py.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Problem with slow httplib connections on Windows (and maybe other platforms)
It cost me a while to analyze the cause of the following problem.
The symptom was that testing a local web app with twill was fast
on Python 2.3, but very slow on Python 2.4-2.6 on a Win XP box.
This boiled down to the problem that if you run a SimpleHTTPServer
for localhost like this,
BaseHTTPServer.HTTPServer(('localhost', 8000),
SimpleHTTPServer.SimpleHTTPRequestHandler).serve_forever()
and access it using httplib.HTTPConnection on the same host like this
httplib.HTTPConnection('localhost', 8000).connect()
then this call is fast using Py 2.3, but slow with Py 2.4-2.6.
I found that this was caused by a mismatch of the ip version used
by SimpleHTTPServer and HTTPConnection for a localhost argument.
What actually happens is the following:
* BaseHTTPServer binds only to the IPv4 address of localhost, because
it's based on TCPServer which has address_family=AF_INET by default.
* HTTPConnection.connect() however tries to connect to all IP addresses
of localhost, in the order determined socket.getaddrinfo('localhost').
With Py 2.3 (without IPv6 support) this is only the IPv4 address,
but with Py 2.4-2.6 the order is (on my Win XP host) the IPv6 address
first, then the IPv4 address. Since the IPv6 address is checked first,
this gives a timeout and causes the slow connect() call. The order by
which getaddrinfo returns IPv4/v6 under Linux seems to vary depending
on the glibc version, so it may be a problem on other platforms, too.
You can see the cause of the slow connect() like this:
import httplib
conn = httplib.HTTPConnection('localhost', 8000)
conn.set_debuglevel(1)
conn.connect()
This is what I get:
connect: (localhost, 8000)
connect fail: ('localhost', 8000)
connect: (localhost, 8000)
The first (failing) connect is the attempt to connect to the IPv6
address which BaseHTTPServer doesn't listen to. (This is the debug
output of Py 2.5 which really should be improved to show the IP address
that is actually used. Unfortunately, in Py 2.6 the debug output when
connecting has even fallen prey to a refactoring. I think it should
either be added again or set_debuglevel() is now pretty meaningless.)
Can we do something about the mismatch that SimpleHTTPServer only serves
IPv4, but HTTPConnection tries to connect with IPv6 first?
I guess other people also stumbled over this, maybe without even
noticing and just wondering about the slow performance. E.g.:
http://schotime.net/blog/index.php/2008/05/27/slow-tcpclient-connection-sockets/
One possible solution would be to improve the TCPServer in the standard
lib so that it determines the address_family and real server_address
based on the first return value of socket.getaddrinfo, like this:
class TCPServer(BaseServer):
...
def __init__(self, server_address, RequestHandlerClass):
if server_address and len(server_address) == 2:
(self.address_family, dummy, dummy, dummy,
server_address) = socket.getaddrinfo(*server_address)[0]
else:
raise TypeError(server_address must be a 2-tuple)
BaseServer.__init__(self, server_address, RequestHandlerClass)
...
That way, if you either serve as or connect to 'localhost', you will
always consistently do this via IPv4 or IPv6, depending on what is
preferred on your platform.
Does this sound reasonable? Any better ideas?
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem with slow httplib connections on Windows (and maybe other platforms)
rdmur...@bitdance.com schrieb: Quoth Christoph Zwerschke c...@online.de: With Py 2.3 (without IPv6 support) this is only the IPv4 address, but with Py 2.4-2.6 the order is (on my Win XP host) the IPv6 address first, then the IPv4 address. Since the IPv6 address is checked first, this gives a timeout and causes the slow connect() call. The order by which getaddrinfo returns IPv4/v6 under Linux seems to vary depending on the glibc version, so it may be a problem on other platforms, too. Based on something I read in another thread, this appears to be a problem only under Windows. Everybody else implemented the TCP/IP stack according to spec, and the IPV6 connect attempt times out immediately, producing no slowdown. Microsoft, however The order in which getaddrinfo returns IPv4 and IPv6 is probably not written in the specs (Posix 1003.1g and RFC 2553). The fact that Windows returns IPv6 addresses first is not wrong in itself. For this discussion, see also http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00869.html https://bugzilla.redhat.com/show_bug.cgi?id=190495 But yes, I also wonder why the connect to the IPv6 loopback address does not time out more quickly on Windows. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with slow httplib connections on Windows (and maybe other platforms)
Steve Holden schrieb: Search for the subject line socket.create_connection slow - this was discovered by Kristjan Valur Jonsson. It certainly seems like a Microsoft weirdness. Thanks for the pointer, Steve. I hadn't seen that yet. I agree that's actually the real problem here. The solution suggested in that thread, using a dual-stacked socket for the TCPserver, seems a good one to me. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
[issue4713] Installing sgmlop can crash xmlrpclib
New submission from Christoph Zwerschke c...@online.de: If you install sgmlop (downloadable from http://effbot.org/downloads/#sgmlop) under Python 2.x, then this can break xmlrpclib. You can reproduce this problem as follows (I have tested with Py 2.4, 2.5 and 2.6): data = ?xml version=1.0 encoding=UTF-8? methodCallmethodNamef/methodNameparams paramvaluek#228;se/value/param /params/methodCall import xmlrpclib assert xmlrpclib.FastParser is None print xmlrpclib.SgmlopParser and 'with' or 'without', 'sgmlop' assert xmlrpclib.loads(data) == ((u'k\xe4se',), 'f') If sgmlop is installed, this gives a UnicodeDecodeError, otherwise everything works well. This happens because xmlrpclib prefers using sgmlop over lib.parsers.expat, but fails to handle numeric character entities properly with this parser. Find attached a patch that fixes this problem. I also wonder whether lib.parsers.expat shouldn't be preferred over sgmlop, since the latter is somewhat outdated, and installing external libraries should not cause crashes or wrong behavior of standard lib modules (see also Issue1772916 for a similar problem). -- components: Library (Lib) messages: 78156 nosy: cito severity: normal status: open title: Installing sgmlop can crash xmlrpclib type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4713] Installing sgmlop can crash xmlrpclib
Changes by Christoph Zwerschke c...@online.de: -- keywords: +patch Added file: http://bugs.python.org/file12418/xmlrpclib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Missing exceptions in PEP 3107
Carl Banks schrieb: You are free to use it for other things. For example, the following usage is obvious and sensible (insofar as listing exceptions is sensible): def f(x : int) - int, raises(TypeError) Think of the return value annotation as more of a function outcome annotation. That's fine, but then this should be mentioned in the PEP3107. Instead it says explicitly that the - syntax is for the type of a function's return value. If it's intended to be used in a more general way like you suggested, then the wording used in the PEP is misleading. (The wording *the* type is problematic anyway, since a Python function can return different types in different situations.) It's still unclear for me whether annotations on thrown exceptions are included in PEP3107 (as per your suggestion), or are not covered by PEP3107 at all (as Duncan suggests), or whether this question has just not yet been settled. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Terry Reedy wrote: I would agree... but... The problem is that code that uses a function hardly cares whether an exception that replaces the normal return is raised explicitly, by a syntax operation (and these are not yet completely documented, though perhaps they should be), or by a function called within the function. I often read that argument that info on thrown exceptions does not matter in Python, but I beg to differ. Just as a simple and well-known example, it is absolutely important to know that the str.index() method throws a ValueError if nothing is found, while the str.find() method should never throw a ValueError. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Carl Banks wrote: If it bothers you that much, go file a bug report. Someone might even change it. But it's nothing but needless pedantry. Has my de domain inspired you to rant about pedantry? No, it does not bother me that much. I just thought the PEP could be clearer here and explicitly mention the thrown exceptions as a use case instead of only speaking about return values. Of course, if you're Dutch, it may be obvious, but for a dimwitted German things are not always obvious. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Matimus wrote: Christoph wrote: Maybe the following syntax would be even more intuitive: def foo(a: a info, b: b info) return ret info raise exc info: return hello world That seems much more intuitive and extensible. The - syntax has always bothered me. The main issue I see with it though is that it might be confusing. Consider: def foo(a, b) return 0: return a + b A person reading the code might be tempted to read the annotation and think that it is the body. Maybe not a huge problem, but definitely something that will come up occasionally. Yes, that's a drawback; and the same problem for a raise clause. Well, yes, but wasn't the whole point of PEP 3107 to get rid of such decorators and provide a single standard way of specifying this kind of info instead? Maybe, but I think it also does two more things: 1. creates a standard location for storing annotations, and 2. Keeps you from violating DRY (http://en.wikipedia.org/wiki/DRY). Using a single decorator for exception info (or even return info) does not violate either of the two stated benefits. The exception information would go into the standard annotations dictionary. The raises decorator does not violate DRY any more or less than it would if added to the language syntax. That's a valid point, but as you already mentioned, the same applies to the return value. In my opinion it is desirable that either both return value and exceptions get a special syntax, or both must be described using decorators. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Carl Banks wrote: I think you're missing the point here. PEP 3017 is policy-neutral: it describes a mechanism to annotate functions and arguments, and that's it. That's not quite true: PEP 3017 describes a mechanism for annotating function parameters *and return values*, and my point was why it does not provide a mechanism for annotating thrown exceptions, since I see info on thrown exceptions in the same category as info on return values. IOW, there is currently no recommended way to do *anything* with annotations(**). That is entirely left up to users and third-party packages, and the PEP goes out of its way to disclaim all authority on policy. The following quote from the PEP sums it up well: Following from point 2, this PEP makes no attempt to introduce any kind of standard semantics, even for the built-in types. This work will be left to third-party libraries. That's right, the PEP does not say how the information is to be *interpreted*, but it does say what the information is *about* (e.g. a certain parameter or the return value). In the same way, you could make annotations about thrown exceptions without actually defining how this information should be interpreted. Your concern is misplaced; it just doesn't belong in the PEP. Call me slow on the uptake, but I still think that if you discuss function annotations and ways of specifying info on return values, then ways of specifying thrown exceptions belong into the same discussion. I understand if you say that for organizational/workflow reasons, the PEP cannot be altered or supplemented any more since it has reached the final status. But as regards contents, I still think it belongs there. (**) - Actually there is a minor policy recommendation: that the pydoc and inspect module learn to understand and display the annotations. What do you mean with understand here when no semantics exists? Do you mean that they should just be able to parse and display them, or that they should start to define the semantics? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Matimus schrieb: The expr in that raises clause should be a list of Exceptions. You are clearly confusing the annotation feature with a possible application of the annotation feature. Annotation could be used for many different applications besides type safety. Sorry, I wanted to say *could* be a list of Exceptions. Though this is the most obvious application. In the end, the annotations need to be given a semantical meaning anyway. Annotation simply creates a dictionary. The name `return` was chosen for the return value because it _is_ a keyword and therefore could not conflict with the name of any of the parameters. Using raises would mean that we would have to introduce the name raises as a new keyword. It would be better just to use they existing keyword raise. Yes, it later also occured to me that it ought to be an existing keyword, i.e. raise (or maybe except). That's porbably the reason why it is throw in C++, and not throws. With all of that being said, a package or application that uses annotation could simply use the data-structure associated with return to also contain exception information. That might not seem intuitive, but keep in mind that the value associated with return in the associations dictionary is going to be a special case anyway. def foo(a: a info, b: b info) - return info, exception info: return hello world That would be possible. But I still think it makes sense to separate them, like so: def foo(a: a info, b: b info) - ret info raise exc info: return hello world And then the annotation dictionary would contain another key raise containing the exc info. This cannot conflict with the name of any other parameter either. Maybe the following syntax would be even more intuitive: def foo(a: a info, b: b info) return ret info raise exc info: return hello world I don't know how determined the - syntax is already. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Duncan Booth wrote: If you really want this then you can use a decorator to insert a 'raise' key into the annotations: Well, yes, but wasn't the whole point of PEP 3107 to get rid of such decorators and provide a single standard way of specifying this kind of info instead? I don't know how determined the - syntax is already. Consider the syntax set in concrete. The meaning of the annotations on the other hand is completely up for grabs. Yes, as far as I understand this is an experiment how people are using the annotations, and then later this may get standardized as well. But maybe the PEP should then at least mention what's the currently recommended way to make annotations about thrown exceptions. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Missing exceptions in PEP 3107
Duncan Booth schrieb: There is no currently recommended way to make such annotations, so how could the PEP mention it? Then it could mention the fact that there is currently no recommended way (and maybe make some suggestions, like those given by you). -- http://mail.python.org/mailman/listinfo/python-list
Missing exceptions in PEP 3107
I'm just reading PEP 3107 (function annotations) and wonder why exceptions are not mentioned there. I think it would be helpful if one could specify which exceptions can be raised by a function, similarly to how it is possible in C++ using the throw clause. The syntax would be something like this: def foo(a: expr, b: expr = 5) raises expr - expr: The expr in that raises clause should be a list of Exceptions. Having the list of possible exceptions as annotation alone would be already helpful. Of course it could be also discussed whether Python should check that the function really raises only these exceptions (as in C++), or we could even have checked exceptions (as in Java, but this seems to be a controversial issue). Has this already been discussed, or is it in a different PEP? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
[issue1697943] msgfmt cannot cope with BOM
Christoph Zwerschke [EMAIL PROTECTED] added the comment: Small improvement of the patch: Instead of hardcoding the BOM as '\xef\xbb\xbf', we should use codecs.BOM_UTF8. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1697943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] sort(reverse=None) prints misleading error message
New submission from Christoph Zwerschke [EMAIL PROTECTED]: When you sort a list with list.sort() or sorted(list), and set the reverse parameter to None, then you get the following misleading error message: TypeError: an integer is required I would expect a more proper error message for the reverse parameter, such as reverse must be a boolean, and maybe reverse=None also accepted as default value, i.e. False. -- components: Interpreter Core messages: 69651 nosy: cito severity: normal status: open title: sort(reverse=None) prints misleading error message type: behavior versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] sort(reverse=None) prints misleading error message
Christoph Zwerschke [EMAIL PROTECTED] added the comment: The problem is not only that the error message TypeError: an integer is required has integer instead of boolean, but it does not mention the attribute name reverse, i.e. it does not even say *where* the integer is required. I firmly believe error messages should not only be technically correct, but also precise, meaningful and helpful for the user. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] Improve error reporting for the argument parsing API
Christoph Zwerschke [EMAIL PROTECTED] added the comment: Agree. Seems to be a more general weakness of the argument parsing of builtin functions and methods, that calls for a general solution instead of a local patch. Luckily there are not so many cases where the errors are misleading, since the builtin functions have very few and mostly positioned parameters, so the problem is not as bad as it seems. There may be only very few cases, like the example above, where the errors are really too unspecific or misleading. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: strip() using strings instead of chars
Duncan Booth schrieb:
if url.startswith('http://'):
url = url[7:]
If I came across this code I'd want to know why they weren't using
urlparse.urlsplit()...
Right, such code can have a smell since in the case of urls, file names,
config options etc. there are specialized functions available. But I'm
not sure whether the need for removing string prefix/suffixes in general
is really so rare that we shouldn't worry to offer a simpler solution.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
strip() using strings instead of chars
In Python programs, you will quite frequently find code like the
following for removing a certain prefix from a string:
if url.startswith('http://'):
url = url[7:]
Similarly for stripping suffixes:
if filename.endswith('.html'):
filename = filename[:-5]
My problem with this is that it's cumbersome and error prone to count
the number of chars of the prefix or suffix. If you want to change it
from 'http://' to 'https://', you must not forget to change the 7 to 8.
If you write len('http://') instead of the 7, you see this is actually
a DRY problem.
Things get even worse if you have several prefixes to consider:
if url.startswith('http://'):
url = url[7:]
elif url.startswith('https://'):
url = url[8:]
You can't take use of url.startswith(('http://', 'https://')) here.
Here is another concrete example taken from the standard lib:
if chars.startswith(BOM_UTF8):
chars = chars[3:].decode(utf-8)
This avoids hardcoding the BOM_UTF8, but its length is still hardcoded,
and the programmer had to know it or look it up when writing this line.
So my suggestion is to add another string method, say stripstr that
behaves like strip, but instead of stripping *characters* strips
*strings* (similarly for lstrip and rstrip). Then in the case above,
you could simply write url = url.lstripstr('http://') or
url = url.lstripstr(('http://', 'https://')).
The new function would actually comprise the old strip function, you
would have strip('aeiou') == stripstr(set('aeio')).
Instead of a new function, we could also add another parameter to strip
(lstrip, rstrip) for passing strings or changing the behavior, or we
could create functions with the signature of startswith and endswith
which instead of only checking whether the string starts or ends with
the substring, remove the substring (startswith and endswith have
additional start and end index parameters that may be useful).
Or did I overlook anything and there is already a good idiom for this?
Btw, in most other languages, strip is called trim and behaves
like Python's strip, i.e. considers the parameter as a set of chars.
There is one notable exception: In MySQL, trim behaves like stripstr
proposed above (differently to SQLite, PostgreSQL and Oracle).
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: strip() using strings instead of chars
Bruno Desthuilliers schrieb:
DRY/SPOT violation. Should be written as :
prefix = 'http://'
if url.startswith(prefix):
url = url[len(prefix):]
That was exactly my point. This formulation is a bit better, but it
still violates DRY, because you need to type prefix two times. It is
exactly this idiom that I see so often and that I wanted to simplify.
Your suggestions work, but I somehow feel such a simple task should have
a simpler formulation in Python, i.e. something like
url = url.lstripstr(('http://', 'https://'))
instead of
for prefix in ('http://', 'https://'):
if url.startswith(prefix):
url = url[len(prefix):]
break
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
[issue2481] locale.strxfrm does not work with Unicode strings
New submission from Christoph Zwerschke [EMAIL PROTECTED]: While locale.strcoll seems to work with Unicode strings, locale.strxfrm gives a UnicodeError. Example: ### try: locale.setlocale(locale.LC_ALL, 'de') except locale.Error: # Windoof locale.setlocale(locale.LC_ALL, 'german') s = ['Ägypten', 'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # works s = [u'Ägypten', u'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # UnicodeError ### Therefore, it is not possible to sort lists of Unicode strings effectively. If possible, this should be fixed. If not possible, this problem should at least be mentioned in the documentation. Currently, the docs do not indicate that strcoll and strxfrm behave differently concerning Unicode. -- components: Unicode messages: 64484 nosy: cito severity: normal status: open title: locale.strxfrm does not work with Unicode strings type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: First post from a Python newbiw
Arnaud Delobelle schrieb: It's a FAQ: http://www.python.org/doc/faq/programming/#how-do-i-create-a-multidimensional-list Somewhere on my todo list I have read through the whole Python FAQ, but so far never got round doing it. Should probably set it to prio A. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: First post from a Python newbiw
Marc 'BlackJack' Rintsch schrieb: On Sun, 02 Mar 2008 14:15:09 +, Steve Turner wrote: Apart from doing something like a=[0,0,0] b=[0,0,0] c=[0,0,0] d=[a,b,c] is there a better way of creating d?? a = [[0] * 3 for dummy in xrange(3)] Why not simply [[0]*3]*3 ? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: tuples, index method, Python's design
Paul Boddie schrieb: On 2 Mar, 19:06, Alan Isaac [EMAIL PROTECTED] wrote: On April 12th, 2007 at 10:05 PM Alan Isaac wrote: The avoidance of tuples, so carefully defended in other terms, is often rooted (I claim) in habits formed from need for list methods like ``index`` and ``count``. Indeed, I predict that Python tuples will eventually have these methods and that these same people will then defend *that* status quo. You were more confident about this than I was. Still, nothing happens if no-one steps up to do something about it. And nobody stepped up because it had been made very clear by Guido and others that they don't want tuples to grow methods. I remember there had been ridiculously excessive threads about this, this probably being one of many others: http://groups.google.de/group/comp.lang.python/browse_thread/thread/430a692bc634a04f/ I don't think this was very encouraging for people who wanted to do something about it. Anyway, it's good to see this happened now. Thanks to Raymond. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
[issue2217] Problem with if clause in generator expression on class level
Christoph Zwerschke added the comment: Thanks, this now makes sense to me. You're right, it's rather an ugly wart than a bug. But I think the Python reference needs to be improved to make this clear enough. How about the following proposed addtions (in square brackets) to section 5.2.5 (http://docs.python.org/ref/genexpr.html): Variables used in the generator expression are evaluated lazily [in the scope of the generator function] when the next() method is called for [the] generator object (in the same fashion as normal generators). However, the leftmost for clause is immediately evaluated [in the current scope] so that [an] error produced by it can be seen before any other possible error in the code that handles the generator expression. Subsequent for [and if] clauses cannot be evaluated immediately since they may depend on the previous for loop. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2217 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Re-raising exceptions with modified message
samwyse wrote: NewStyle.__name__ = old.__class__.__name__ Simple, but that does the trick! new.__dict__ = old.__dict__.copy() Unfortunately, that does not work, since the attributes are not writeable and thus do not appear in __dict__. But my __getattr__ solution does not work either, since the attributes are set to None when initialized, so __getattr__ is never called. Need to think about this point some more... Anyway, the beer is on me ;-) -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Christoph Zwerschke wrote:
But my __getattr__ solution does not work either, since the attributes
are set to None when initialized, so __getattr__ is never called.
Here is a simple solution, but it depends on the existence of the args
attribute that will eventually be deprecated according to the docs:
def PoliteException(e):
E = e.__class__
class PoliteException(E):
def __str__(self):
return str(e) + , sorry!
PoliteException.__name__ = E.__name__
return PoliteException(*e.args)
try:
unicode('\xe4')
except Exception, e:
p = PoliteException(e)
assert p.reason == e.reason
raise p
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Christoph Zwerschke wrote:
Here is a simple solution, but it depends on the existence of the args
attribute that will eventually be deprecated according to the docs:
Ok, here is another solution that does not depend on args:
def PoliteException(e):
E = e.__class__
class PoliteException(E):
def __init__(self):
for arg in dir(e):
if not arg.startswith('_'):
setattr(self, arg, getattr(e, arg))
def __str__(self):
return str(e) + , sorry!
PoliteException.__name__ = E.__name__
return PoliteException()
try:
unicode('\xe4')
except Exception, e:
p = PoliteException(e)
assert p.reason == e.reason
raise p
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Christoph Zwerschke wrote:
Here is a simple solution, but it depends on the existence of the args
attribute that will eventually be deprecated according to the docs:
Just found another amazingly simple solution that does neither use teh
.args (docs: will eventually be deprecated) attribute nor the dir()
function (docs: its detailed behavior may change across releases).
Instead it relies on the fact that the exception itselfs behaves like
its args tuple (checked with Py 2.3, 2.4 and 2.5).
As another twist, I set the wrapper exception module to the module of
the original exception so that the output looks more like the output of
the original exception (i.e. simply UnicodeDecodeError instead of
__main__.UnicodeDecodeError).
The code now looks like this:
def PoliteException(e):
E = e.__class__
class PoliteException(E):
def __str__(self):
return str(e) + , sorry!
PoliteException.__name__ = E.__name__
PoliteException.__module__ = E.__module__
return PoliteException(*e)
try:
unicode('\xe4')
except Exception, e:
p = PoliteException(e)
assert p.reason == e.reason
raise p
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
samwyse wrote: TypeError: __class__ must be set to a class Excpt ceratinly appears to be a class. Does anyone smarter than me know what's going on here? Not that I want to appear smarter, but I think the problem here is that exceptions are new-style classes now, whereas Empty is an old-style class. But even if you define Empty as a new-style class, it will not work, you get: TypeError: __class__ assignment: only for heap types This tells us that we cannot change the attributes of a built-in exception. If it would be possible, I simply would have overridden the __str__ method of the original exception in the first place. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
ANN: Webware and DBUtils 0.9.4 released
Webware 0.9.4 and DBUtils 0.9.4 have been released. The new release of Webware for Python contains some fixes and improvements of WebKit, and it adds some more configuration settings that have been requested by users. The details can be found in the WebKit release notes. The new DBUtils release fixes a problem in the destructor code and has been supplemented with a German user's guide. Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. DBUtils is a suite of tools providing solid, persistent and pooled connections to a database that can be used in all kinds of multi-threaded environments such as Webware for Python or other web application servers. The suite supports DB-API 2 compliant database interfaces and the classic PyGreSQL interface. Check out the Webware for Python home page at http://www.w4py.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Re-raising exceptions with modified message
Did you run this? With Py 2.5 I get a syntax error, and with Py 2.5 I get: new.__class__ = old.__class__ TypeError: __class__ must be set to a class -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
samwyse wrote: def test(code): try: code() except Exception, e: try: raise e.__class__, str(e) + , sorry! except TypeError: raise SorryFactory(e)() Ok, you're suggestig the naive approach if it works and the factory approach I came up with last as a fallback. Maybe a suitable compromize. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Gerard Flanagan wrote: Would a decorator work here? Depends on how you want to use that functionality. In my use case I only need to catch the excpetion once. Note that in your code the exception has not the right type which is what I targeted in my last posting. I.e. the following will raise an Exception if function is decorated: try: print funktion() except ArithmeticError: pass -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re-raising exceptions with modified message
What is the best way to re-raise any exception with a message
supplemented with additional information (e.g. line number in a
template)? Let's say for simplicity I just want to add sorry to every
exception message. My naive solution was this:
try:
...
except Exception, e:
raise e.__class__, str(e) + , sorry!
This works pretty well for most exceptions, e.g.
try:
... 1/0
... except Exception, e:
... raise e.__class__, str(e) + , sorry!
...
Traceback (most recent call last):
File stdin, line 4, in module
ZeroDivisionError: integer division or modulo by zero, sorry!
But it fails for some exceptions that cannot be instantiated with a
single string argument, like UnicodeDecodeError which gets converted
to a TypeError:
try:
... unicode('\xe4')
... except Exception, e:
... raise e.__class__, str(e) + , sorry!
...
Traceback (most recent call last):
File stdin, line 4, in module
TypeError: function takes exactly 5 arguments (1 given)
Another approach is using a wrapper Extension class:
class SorryEx(Exception):
def __init__(self, e):
self._e = e
def __getattr__(self, name):
return getattr(self._e, name)
def __str__(self):
return str(self._e) + , sorry!
try:
unicode('\xe4')
except Exception, e:
raise SorryEx(e)
But then I get the name of the wrapper class in the message:
__main__.SorryEx: 'ascii' codec can't decode byte 0xe4 in position 0:
ordinal not in range(128), sorry!
Yet another approach would be to replace the __str__ method of e, but
this does not work for new style Exceptions (Python 2.5).
Any suggestions?
-- Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Thomas Heller wrote: I have the impression that you do NOT want to change the exceptions, instead you want to print the traceback in a customized way. But I may be wrong... No, I really want to modify the exception, supplementing its message with additional information about the state of the program. The use case are compiled Kid templates (http://kid-templating.org). If an error occurs, I want to add the corresponding line number of the XML file as information for the template developer. Since the final error handling may happen somewhere else (e.g. by TurboGears importing a Kid template), I do not want to modify trackeback handling or something. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Neil Cerutti wrote: The documentation for BaseException contains something that might be relevant: [...] If more data needs to be attached to the exception, attach it through arbitrary attributes on the instance. All Users could get at the extra info you attached, but it wouldn't be automatically displayed by the interpreter. Yes, that's the problem here. It wouldn't be displayed automatically and the users must be aware of this attribute. I'd like to have a more transparent solution. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: s1.intersects(s2)
Nis Jørgensen wrote: The problem is, these functions can be read as X is [consisting only of] digit[s], X is lower [case] etc, where the bits in brackets have been removed for brewity. In the case of s1 is intersect s2 there is no way I can see of adding words to get a correct sentence. The obvious naming is s1.intersects(s2) which reads as s1 intersects s2, a perfectly cromulent sentence. Agree. A possible alternative would be s1.hasintersection(s2), but s1.intersects(s2) is ok as well. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Neil Cerutti wrote:
You may need the traceback module to get at the error message, if
trying to read e.message can fail.
Something like this mess here: ;)
...
except Exception, e:
etype, evalue, etb = sys.exc_info()
ex = traceback.format_exception_only(etype, evalue)
message = ex[0].partition(':')[2].strip()
raise etype, message+. Sorry!, etb
Note that the above will break for SyntaxError (who's message
contains more than one line) and any kind of exception that
doesn't inherit from Exception.
That's actually similar to what I was using in Kid already.
The problem is that there are some Exceptions which cannot be
instantiated with a single string argument, such as UnicodeDeocdeError.
Please try the above with unicode('\xe4') instead of the dots.
Instead of re-raising the UnicodeDecodeError, you will get a TypeError
because of this problem.
-- Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: s1.intersects(s2)
Steven D'Aprano wrote: I'm not a professional set theorist, but in 15-odd years of studying and teaching maths I've never come across mathematicians using intersect as a verb except as informal short-hand. I often say North Street and South Street don't intersect, but the intersection of sets A and B is empty. I think mathematicians use more often the inverse predicate, namely disjoint, which is well defined as having an empty intersection. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Kay Schluehr wrote: If you are sure that the exception isn't caught on another level just use the following showtraceback() function, manipulate it's output slightly and terminate your program with sys.exit() That's what I want to avoid. In my case the error is displayed and evaluated in a completly different piece of software. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Seems that no simple solution exists,
so for now, I will be using something like this:
class PoliteException(Exception):
def __init__(self, e):
self._e = e
def __getattr__(self, name):
return getattr(self._e, name)
def __str__(self):
if isinstance(self._e, PoliteException):
return str(self._e)
else:
return '\n%s: %s, I am sorry!' % (
self._e.__class__.__name__, str(self._e))
try:
unicode('\xe4')
except Exception, e:
raise PoliteException(e)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Sorry for the soliloquy, but what I am really using is the following so
that the re-raised excpetion has the same type:
def PoliteException(e):
class PoliteException(e.__class__):
def __init__(self, e):
self._e = e
def __getattr__(self, name):
return getattr(self._e, name)
def __str__(self):
if isinstance(self._e, PoliteException):
return str(self._e)
else:
return '\n%s: %s, I am sorry!' % (
self._e.__class__.__name__, str(self._e))
return PoliteException(e)
try:
unicode('\xe4')
except Exception, e:
raise PoliteException(e)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Re-raising exceptions with modified message
Alex Popescu wrote: Probably the simplest solution would be to create a new exception and wrapping the old one and the additional info. Unfortunately, this may have a huge impact on 3rd party code that was catching the original exception. So, I think you should create an utility factory-like function that is either creating a new exception instance as the one caught and with the additional information, Right, I have gone with that (see the example with the PoliteException class somewhere below). or an utility that knows how to modify the caught exception according to its type. I guess you mean something like this (simplified): except Exception, e: if getattr(e, 'reason'): e.reason += sorry else: e.message += sorry The problem is that these attribute names are not standardized and can change between Python versions. Not even args is sure, and if a class has message it does not mean that it is displayed. Therefore I think the first approach is better. In the first case you will need somehow to tell to the new instance exception the real stack trace, because by simply raising a new one the original stack trace may get lost. Yes, but thats a different problem that is easy to solve. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
ANN: Webware 0.9.3 released
Webware 0.9.3 has been released. This release of Webware for Python includes a couple of fixes and improvements of WebKit and some cleanup of the overall Webware codebase. Please have a look at the WebKit release notes for details. Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. Check out the Webware for Python home page at http://www.w4py.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Problem with reimporting modules
I'm currently investigating a problem that can hit you in TurboGears when Kid template modules are reloaded in the background, because in certain situations, global variables suddenly are set to None values. I tracked it down to the following behavior of Python. Assume you have a module hello.py like that: hello. py greeting = 'Hello!' def print_hello(): print greeting --- Now run the following code: from hello import print_hello print_hello() import sys del sys.modules['hello'] # delete module import hello # recreate module print_hello() The second print_hello() prints None instead of Hello!. Why is that? I had expected that it either prints an error or print Hello! as well. Is this intended behavior of Python? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with reimporting modules
Yes I know about reload(), but TurboGears (TurboKid) does not use it and the docs say that removing modules from sys.module is possible to force reloading of modules. I don't want to rewrite everything since it's a pretty complex thing with modules which are compiled from templates which can depend from other templates etc... -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with reimporting modules
Thanks for the detailed explanations, Gabriel. At that time, all values in the module namespace are set to None (for breaking possible cycles, I presume). print_hello now has a func_globals with all names set to None. (Perhaps the names could have been deleted instead, so print_hello() would raise a NameError, but I'm just describing the current CPython implementation) Yes, that was the thing that confused me a bit. I had expected that an error is raised or that the namespace has a reference to the module and is reestablished when the module has been reloaded. Anyway, I have solved the problem in a different way now. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: No latin9 in Python?
Martin v. Löwis schrieb: Christoph Zwerschke schrieb: Shall I proceed writing such a patch? Shall I also add latin0 and l0 which are other inofficial aliases? Sure, go ahead. I see no need for the latin0/l0 aliases, though: they predate the formal adoption of iso-8859-15, and should be phased out by now (I'm sure that somebody will provide an example of a software that still uses it, but I likely won't find that single example convincing). Ok, I'll add the alias for latin9, the completely missing latin10, and will also have a look whether some other things are missing. But probably I'll only get round to doing so after the Christmas holidays. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: tuple.index()
Hendrik van Rooyen wrote: From a practical point of view, the only reason to use a tuple instead of a list for anything seems to be that you want to use it as a key in a dict... Otherwise, why bother with these recalcitrant things that you can't change or index, or append to or anything that lists allow? I can imagine (but don't know whether this is actually the case in CPython) that tuples have some memory and/or performance advantages over lists, and there could be special optimizations for small (2 or 3 element) tuples because they are used very frequently. So that would be another practical aspect why a long list of tuples could be better than a long list of lists - but does anybody know whether this is even true for CPython? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: tuple.index()
James Stroud wrote: Christoph Zwerschke wrote: Maybe there would be less dispute if this dogma/convention(?) Tuples are for heterogeneous data, list are for homogeneous data would be written down somewhere in the tutorial, reference or in PEP8, so people would be aware of it. This is a good idea. It has taken me a while to begin using them in this manner. I have been more or less forced to by the design of the language and I confess that the intended usage of each is pretty natural. I just found that there is indeed some mentioning in the FAQ here: http://www.python.org/doc/faq/general/#why-are-there-separate-tuple-and-list-data-types But it is a bit vague, too, and does not mention whether there is any difference in efficiency which would be interesting to know as well. It would be nice if somebody with more knowledge about the internals could overhaul and supplement that answer in the FAQ. A link to this in the tutorial or other parts of the standard doc where tuples and lists are discussed would be also helpful. Concretely speaking, which data type should I use for coordinate tuples? Usually, tuples are used. Does this mean that I should better use lists from now on because all the components have the same type? I don't think that all homogenous structures should be lists. This is not the same as saying that all lists should be homogenous. So in which cases exactly should one make exceptions? Python experts probably decide this from their gut feelings but it would be nice to have a more complete rule of thumb or decision guidance for non-experts that is mentioned somewhere in the docs, too: Must be hashable for use as dict key or set element -- tuple Inhomogenous in some meaning of the word -- tuple ... (fill in the details) -- tuple everything else -- list Maybe we can agree on something concrete here. -- http://mail.python.org/mailman/listinfo/python-list
Re: tuple.index()
Maybe there would be less dispute if this dogma/convention(?) Tuples are for heterogeneous data, list are for homogeneous data would be written down somewhere in the tutorial, reference or in PEP8, so people would be aware of it. And can somebody explain what is exactly meant with homogenous data? That the type of the elements is the same in some technical or philosophical meaning? Concretely speaking, which data type should I use for coordinate tuples? Usually, tuples are used. Does this mean that I should better use lists from now on because all the components have the same type? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: No latin9 in Python?
Martin v. Löwis wrote: While you are at it, you'll notice that the current version of the character-sets database lists Name: ISO-8859-15 MIBenum: 111 Source: ISO Please see: http://www.iana.org/assignments/charset-reg/ISO-8859-15 Alias: ISO_8859-15 Alias: Latin-9 so the official alias is Latin-9, not latin9. You may want to ask the submitter of that entry why this inconsistency was introduced. Unfortunately, I got no reply and I really cannot see any reason for this inconsistency; probably it was a mistake or carelessness. According to http://recode.progiciels-bpi.ca/manual/Tabular.html, l9 and latin9 are aliases for this charset. Source: ISO 2375 registry. So I think it cannot harm adding latin9 as an alias name. Latin-9 will then be recognized automatically since I think capitalization and hyphens do not matter anyway (I'll check that). Shall I proceed writing such a patch? Shall I also add latin0 and l0 which are other inofficial aliases? -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: tuple.index()
Tim Golden wrote: Christoph Zwerschke wrote: And can somebody explain what is exactly meant with homogenous data? This seems to have been explained a few times recently :) Basically, if you have a list of xs and remove one item from it, it is still a list of xs, According to that definition, everything would be homogenous. I guess what you wanted to say is if you have an x and remove one item from it it is still an x, then it's homogenous. The problem is that depending on how exactly you define x, you will come to different results. If you have a tuple containing, say, a 2d coordinate pair, and remove something from it, it's no longer a coordinate pair. Now here comes the ambiguity. If you interpret x as coordinate tuple it would be still one (a 1-tuple), but if you interpret x as coordinate pair then it would indeed not be an x any more. So that definition is not really helpful. A typical example of their combined use is a set of rows returned from a database: each row is a tuple of fields, the same as all other such rows, and removing or adding a field would make no sense. However, add a new row to the list and it remains a list of rows. Sounds plausible. But when I read a row with the name and forename of a person, I might want to collapse the name and forename into one element before I hand it over to a function that will display it as a table. Or I may want to delete certain elements which are not important. In such cases, having each row as list may also make sense. Concretely speaking, which data type should I use for coordinate tuples? Usually, tuples are used. Does this mean that I should better use lists from now on because all the components have the same type? This would seem to be slightly false logic (and very possibly used tongue-in-cheek). Heterogeneous data doesn't mean that each item *has* to be different, merely that they *may* be. I don't think it's a problem of false logic but the problem that homogenous data is not defined. We probably agree that it usually makes perfect sense to use tuples for coordinates. But in certain mathematical algorithms it also makes sense to ask for the number of zero components of a coordinate tuple - the count() method would be helpful here. The statement if you are looking for index() or count() for your tuples, you're using the wrong container type is too extreme I think. I would agree with it *may indicate* that you should better use lists. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
No latin9 in Python?
I noticed that Python does not understand the codec alias names latin7 = iso8859-13, latin9 = iso8859-15 (see http://docs.python.org/lib/standard-encodings.html). Particularly latin9 is pretty popular here in Western Europe since it contains the Euro symbol (contrary to latin1). According to the Wikipedia (http://en.wikipedia.org/wiki/ISO-8859), the latin7 and latin9 aliases seem to be official, at least they are widely used an accepted. In PostgreSQL, LATIN9 is even the name of the charset, and iso8859-15 is the alias name: http://www.postgresql.org/docs/8.2/static/multibyte.html#CHARSET-TABLE Is there anything speaking against adding these as aliases? If no, I would submit a patch. (Also, Python does not support the latin10=iso8859-16 charset. I could try to add that as well.) -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against SQL injection
Tor Erik Soenvisen wrote:
How safe is the following code against SQL injection:
# Get user privilege
digest = sha.new(pw).hexdigest()
# Protect against SQL injection by escaping quotes
uname = uname.replace(', '')
sql = 'SELECT privilege FROM staff WHERE ' + \
'username=\'%s\' AND password=\'%s\'' % (uname, digest)
res = self.oraDB.query(sql)
This is definitely *not* safe.
For instance, set uname = r\' or 1=1 --
You must replace the backslash with a double backslash as well.
But as already suggested, you should better use query parameters.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug in urllib?
goyatlah wrote:
urllib.url2pathname(http://127.0.0.1:1030/js.cgi?pcaamp;r=12181;)
gives IOError : Bad Url, only coz of the :1030 which should be
accurate portnumber. Is it something I did wrong, or a bug. And what
to do to avoid this (except rewriting url2pathname)?
help(urllib.url2pathname)
url2pathname(url)
OS-specific conversion from a relative URL of the 'file' scheme
to a file system path; not recommended for general use.
So first, you must use a URL of the 'file' scheme, not of the 'http'
scheme. This is something like:
'file://localhost/C|/srv/cgi.bin/js.cgi' or 'file:///C|/srv/cgi.bin/js.cgi
Second, it must be a relative URL which is a bit mistakable here. What
is actually meant is that you must not prepend it with 'file:'.
So you have to pass
'//localhost/C|/srv/cgi.bin/js.cgi' or
'///C|/srv/cgi.bin/js.cgi'
On Windows, this will give you:
urllib.url2pathname('//localhost/C|/srv/cgi.bin/js.cgi')
C:\srv\cgi.bin\js.cgi
The docs at http://docs.python.org/lib/module-urllib.html say basically
the same, you need to pass the *path component* of an URL, not the
complete URL.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
ANN: DBUtils 0.9.2 has been released
DBUtils 0.9.2 has been released. DBUtils is a suite of tools providing solid, persistent and pooled connections to a database that can be used in all kinds of multi-threaded environments such as Webware for Python or other web application servers. The suite supports DB-API 2 compliant database interfaces and the classic PyGreSQL interface. The new version is available for download at: * http://www.python.org/pypi/DBUtils/ and * http://www.w4py.org/downloads/DBUtils/ Changes: * http://www.w4py.org/DBUtils/Docs/RelNotes-0.9.2.html User's Guide available at: * http://www.w4py.org/DBUtils/Docs/UsersGuide.html -- Christoph Zwerschke -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
ANN: Webware 0.9.2 released
Webware 0.9.2 has been released. This release of Webware for Python includes a couple of fixes and improvements of WebKit, MiddleKit, MiscUtils and WebUtils (see the respective release notes). Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. Check out the Webware for Python home page at http://www.w4py.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Python less error-prone than Java
Martin v. Löwis wrote: In Python 2.4 and later, you could write def Distance(t1, t0, maxint=(132)-1): return (t1-t0) maxint No, this function behaves differently. It never returns a negative value. The only difference in Python 2.4 is that 132 was 0 before. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
Ilpo Nyyssönen wrote: It is not different. Your crash can tell you that it was a null pointer. Your crash can tell you that you stomped over memory. You just get the information about the error in different way. Not all stomping over memory must result in a crash. You might just get wrong results, and you don't notice it. Also, if you get such a crash it's much harder to find out the reason. It may show off only later in a different part of the program. -- Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: How to search for substrings of a string in a list?
Girish Sahani schrieb:
Given a length k string,i want to search for 2 substrings (overlap
possible) in a list consisting of length k-1 strings. These 2 substrings
when 'united' give the original string.
e.g given 'abc' i want to search in the list of 2-length strings
['ab',ac','cd','bc','bd'] to extract either
1) 'ab and 'ac' OR ('a' common)
2) 'ab' and 'bc' OR ('b' common)
3) 'ac' and 'bc' ('c' common)
Here is a simple brute force solution that also works for different
lengths of your strings:
complete = 'abc'
partial = ['ab','ac','cd','bc','bd']
for i1, s1 in enumerate(partial):
for s2 in partial[i1+1:]:
if set(s1).union(set(s2)) == set(complete):
print s1, s2
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: finding file
su wrote: could someone help me on how can i restrict my code to search the file in the current dir only Use os.listdir(). -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
Simon Percivall wrote: First: It's perfectly simple in Java to create a binary sort that sorts all arrays that contain objects; so wrong there. My point was that the *same* Java source example, directly converted to Python would *automatically* accept all kinds of arrays. And the same code converted to SML would automatically work on all kinds of arrays and SML is statically typed. It's a language issue, not a typing issue. Ok, here the point was that Java has *explicit* static typing. SML is not a procedural language and uses *implicit* static typing. Therefore it shares some of the benefits of dynamically typed languages such as Python. However, an SML version of the program would probably still have the same bug as the Java version, right? No need to make any extra efforts. By the way, how would you do it in Java? With function overloading? I would not call that perfectly simple. Since Java doesn't allow function overloading that clearly can't be the way. J2SE 5.0 allows generic classes and functions that operate on generic containers. There are some gotchas, but it's not drastically more complex than the original int-only java code. Java doesn't allow function overloading? That would be new to me. Or did you just want to nitpick that it should be more properly called method overloading in Java? And as you already said, there are some gotchas and you would have to wrap int and long etc. I still would not call that perfectly simple, as it is in Python. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
Kaz Kylheku wrote: You can have statically typed languages with inadequate type safety, and you can have dynamically typed languages with inadequate type safety. But the point in this example was that the Java program ironically had the bug *because* Java handles ints in a type-safe way, while Python does not. What's better about the Python version? First, it will operate on *any* sorted array, no matter which type the values have. Uh huh! With hard-coded and = operators, how stupid. What if you want to use it on strings? Would that be a case-insensitive lexicographic comparison, or case-insensitive? How do you specify what kind of less-than and equal you want to do? Where's the problem? The function uses the standard ordering of the values you feed to it, i.e. case-insensitive lexicographical order if you feed a lis of ordinary tuples of strings. You can also feed objects with a different ordering, like case-insensitive. Anyway, that was completely not the point. The point was that you could take that Java program, convert it directly to Python, and have automatically eliminated a bug. I did not claim that the resulting Python program was automatically a real good and Pythonic one. -1 to indicate not found? Why copy Java braindamage induced by an antiquated form of static typing? The Java version has to do that So you would call Python's str.find() method braindamaged as well? But as I said, that was not the point here anyway. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
nikie wrote:
Let's look at two different examples: Consider the following C# code:
static decimal test() {
decimal x = 10001;
x /= 100;
x -= 100;
return x;
It returns 0.01, as you would expect it.
Yes, I would expect that because I have defined x as decimal, not int.
Now, consider the python equivalent:
def test():
x = 10001
x /= 100
x -= 100
return x
No, that's not the Python equivalent. The equivalent of the line
decimal x = 10001
in Python would be
x = 10001.0
or even:
from decimal import Decimal
x = Decimal(10001)
Setting x = 10001 would be equivalent to the C# code
int x = 10001
It returns 0. Clearly an error!
That's not clearly an error. If you set int x = 10001 in C#, then you
also get a 0. By setting x to be an integer, you are implicitely
telling Python that you are not interested in fractions, and Python does
what you want. Granted, this is arguable and will be changed in the
__future__, but I would not call that an error.
By the way, the equivalent Python code to your C# program gives on my
machine the very same result:
x = 10001.0; x /= 100; x -= 100; print x
0.01
Even if you used from __future__ import division, it would actually
return 0.015116, which, depending on the context, may
still be an intolerable error.
With from __future__ import division, I also get 0.01 printed. Anyway,
if there are small discrepancies then these have nothing to do with
Python but rather with the underlying floating-point hardware and C
library, the way how you print the value and the fact that 0.01 can
principally not be stored exactly as a float (nor as a C# decimal), only
as a Python Decimal.
I can even think of an example where C's (and Java's) bounded ints are
the right choice, while Python's arbitraty-precision math isn't:
Assume you get two 32-bit integers containing two time values (or
values from an incremental encoder, or counter values). How do you
find out how many timer ticks (or increments, or counts) have occured
between those two values, and which one was earlier? In C, you can
just write:
long Distance(long t1, long t0) { return t1-t0; }
And all the wraparound cases will be handled correctly (assuming there
have been less than 2^31 timer ticks between these two time values).
Distance will return a positive value if t1 was measured after t0, a
negative value otherwise, even if there's been a wraparound in
between. Try the same in Python and tell me which version is simpler!
First of all, the whole problem only arises because you are using a
statically typed counter ;-) And it only is easy in C when your counter
has 32 bits. But what about a 24 bit counter?
Anyway, in Python, you would first define:
def wrap(x, at=131):
if x -at:
x += at*2
elif x = at:
x -= at*2
return x
Then, the Python program would be as simple:
Distance = lambda t1,t0: wrap(t1-t0)
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
nikie wrote: Hm, then I probably didn't get your original point: I thought your argument was that a dynamically typed language was safer because it would choose the right type (in your example, an arbitrary-pecision integer) automatically. No, my point was not to make a general statement. It just stumbled over that example and said to myself that wouldn't have happend with Python. And I thought it might be interesting for people on c.l.p as well. That was all. As you can see from the above sample, it sometimes picks the wrong type, too. Now you tell me that this doesn't count, because I should have told Python what type to use. Yes. Python did not pick that type - you explicitely said that x should an int by setting x = 10001. I mean, you could have told Java to used a 64-bit or arbitrary-length integer type instead of a 32-bit integer (which would actually be equivalent to the Python code), so it would do the same thing as the Python binary search implementation. Right, but then Java would do all index operations in that type, even for very small arrays when it's not necessary. That's why people probably don't do it. The is OT, but what makes you think a C# decimal can't store 0.01? A C# data type summary gave me the impression that it was just a more accurate but still binary floating point type. But you're right, the name decimal should have given me a clue that it uses base 10 ;-) So sorry for the confusion. Forget what I wrote about float. I should have corretly written that the equivalent to the C# statement decimal x = 10001; is the following Python statement x = Decimal(10001) If you do the equivalent thing, Python will give the same result as C#. All I wanted to point out is that bounded integers do have their advantages, because some people in this thread apparently have never stumbled over them. Sure, I did not want to deny that. The main advantages are speed, and dealing with hardware related issues. Your Distance function in C is of course much faster than my Python implementation. Surely I wouldn't want to write a device driver in Python. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Python less error-prone than Java
You will often hear that for reasons of fault minimization, you should
use a programming language with strict typing:
http://turing.une.edu.au/~comp284/Lectures/Lecture_18/lecture/node1.html
I just came across a funny example in which the opposite is the case.
The following is a binary search algorithm in Java. It searches a value
in an ordered array a of ints:
public static int binarySearch(int[] a, int key) {
int low = 0;
int high = a.length - 1;
while (low = high) {
int mid = (low + high) / 2;
int midVal = a[mid];
if (midVal key)
low = mid + 1;
else if (midVal key)
high = mid - 1;
else
return mid; // key found
}
return -(low + 1); // key not found.
}
Now the same thing, directly converted to Python:
def binarySearch(a, key):
low = 0
high = len(a) - 1
while low = high:
mid = (low + high) / 2
midVal = a[mid]
if midVal key:
low = mid + 1
elif midVal key:
high = mid - 1;
else:
return mid # key found
return -(low + 1) # key not found.
What's better about the Python version? First, it will operate on *any*
sorted array, no matter which type the values have.
But second, there is a hidden error in the Java version that the Python
version does not have.
See the following web page if you dont find it ;-)
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
Simon Percivall wrote: First: It's perfectly simple in Java to create a binary sort that sorts all arrays that contain objects; so wrong there. My point was that the *same* Java source example, directly converted to Python would *automatically* accept all kinds of arrays. No need to make any extra efforts. By the way, how would you do it in Java? With function overloading? I would not call that perfectly simple. Secondly: The bug has nothing to do with static typing (I'm guessing that's what you meant. Both Python and Java are strongly typed). The problem is that ints are bounded in Java. They could easily have been ints and then automatically coerced to (equivalent to) longs when they got bigger; that they aren't is more a design fault than anything to do with static typing. The equivalent in Python would have been if an overflow exception was raised when the int got too big. It might have been that way, typing or no typing. Yes, sorry, I meant static typing, not strict typing. But I still do think that the bug has to do with static typing. You're right, the direct cause is that ints are bounded in Java, and not bounded in Python, and that it could well be the other way round. However, doing it the other way round would not be so clever and appropriate for the respective language due to the difference in static typing. Java could coerce the result to long, but then it would still crash when the result is stored back to the statically typed variable. So that would not be very clever. And Python could produce an overflow error (and did in the past), but taking advantage of the possibilities of dynamic typing and automatically producing longs is a cleverer solution for Python, and that's why it was proposed and accepted in PEP237. So the difference in static typing is actually the deeper reason why ints were made to behave differently in the two languages. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
Cameron Laird wrote: So, here's my summary: Python's a nice language--a very nice one. It's safer to use than Java in many ways. Python's typing is STRICTER than Java's, but it's also dynamic, so people get to argue for decades about which is a better model. Anyone who thinks typing is a first-order determinant of code quality is making a big mistake though, anyway. Yes, sorry. It has nothing to do with strict, but with static typing. And I should not have chosen such a general subject line (I just meant to be funny, but sounded more like a troll). I had just noticed that the direct translation of that Java program to Python would not have that subtle bug and found that this was worth mentioning. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
