[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id EF0611DE20 for ; Sun, 18 Dec 2011 20:23:39 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3T5wK759MkzQ00 for ; Sun, 18 Dec 2011 20:23:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1324236219; bh=/yIht6I8EmPEiXZ9KLwjVNemYVkalK/1gPj7HIPxFXM=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=oFlrztFHjmQi6JK3VCXIic9qr39+OWQ4rGmVoFTk59ABwcLwBJpJGa4BQq74DRZT9 BoWSENTtwjmDIiLNg3LgIXv9RioJHWtR6EWlj1R7fvPUfTgnjXd7fJNgbVSPG5BbgU VzVC5bQYIO9aKpzYWBTTxH700UdCfLAC27/GwIKY= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 18 Dec 2011 20:23:39 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Sun, 18 Dec 2011 20:23:39 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1RcMKh-0006D3-Ii for [email protected]; Sun, 18 Dec 2011 20:23:39 +0100 Date: Sun, 18 Dec 2011 20:23:39 +0100 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue7502] TmV3IGNoYW5nZXNldCBlMzdjNzE2OTg0MDkgYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICcz LjInOgpGb2xsb3d1cCB0byAjNzUwMjogYWRkIF9faGFzaF9fIG1ldGhvZCBhbmQgdGVzdHMuCmh0 dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2L2UzN2M3MTY5ODQwOQoKCk5ldyBjaGFuZ2Vz ZXQgNGZmYTk5OTJhN2Q4IGJ5IEFudG9pbmUgUGl0cm91IGluIGJyYW5jaCAnZGVmYXVsdCc6CkZv bGxvd3VwIHRvICM3NTAyOiBhZGQgX19oYXNoX18gbWV0aG9kIGFuZCB0ZXN0cy4KaHR0cDovL2hn LnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvNGZmYTk5OTJhN2Q4Cg== ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
> Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum What's the rationale for that change? It's a valid kind value, after all, and the C convention is that an enumeration lists all valid values (else there wouldn't be a need for an enumeration in the first place). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
On 18/12/2011 20:34, "Martin v. Löwis" wrote: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum What's the rationale for that change? It's a valid kind value, after all, and the C convention is that an enumeration lists all valid values (else there wouldn't be a need for an enumeration in the first place). PyUnicode_KIND() only returns PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND or PyUnicode_4BYTE_KIND. Outside unicodeobject.c, you are not supposed to see PyUnicode_WCHAR_KIND. For switch/case, it avoids the need of adding a dummy PyUnicode_WCHAR_KIND case (or a default case). Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
Am 18.12.2011 20:45, schrieb Victor Stinner: > On 18/12/2011 20:34, "Martin v. Löwis" wrote: >>>Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum >> >> What's the rationale for that change? It's a valid kind value, after >> all, and the C convention is that an enumeration lists all valid values >> (else there wouldn't be a need for an enumeration in the first place). > > PyUnicode_KIND() only returns PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND > or PyUnicode_4BYTE_KIND. Outside unicodeobject.c, you are not supposed > to see PyUnicode_WCHAR_KIND. Why do you say that? It can very well happen, assuming you call PyUnicode_KIND on a string that is not ready. That would be a bug in the module, but people do make bugs when programming. > For switch/case, it avoids the need of adding a dummy > PyUnicode_WCHAR_KIND case (or a default case). ... and thus hides a potential source of errors, as people may forget to call ready, and then fall through the case, letting god-knows-what happen. If the rationale is to simplify silencing compiler errors, I vote for reverting the enumeration back to a macro list. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
On 18/12/2011 21:04, "Martin v. Löwis" wrote: PyUnicode_KIND() only returns PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND or PyUnicode_4BYTE_KIND. Outside unicodeobject.c, you are not supposed to see PyUnicode_WCHAR_KIND. Why do you say that? It can very well happen, assuming you call PyUnicode_KIND on a string that is not ready. That would be a bug in the module, but people do make bugs when programming. I added assert(PyUnicode_IS_READY(op)) to the macro, so the bug will be quickly catched in debug mode. I forgot that it is just an assertion and few people use Python compiled in debug mode. If the rationale is to simplify silencing compiler errors, I vote for reverting the enumeration back to a macro list. I'm not sure that gcc will not complain if only 3 values are handled. I agree to revert the commit if that helps developers to write bugs. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Move PyUnicode_WCHAR_KIND outside PyUnicode_Kind enum
Am 18.12.2011 21:16, schrieb Victor Stinner: > On 18/12/2011 21:04, "Martin v. Löwis" wrote: >>> PyUnicode_KIND() only returns PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND >>> or PyUnicode_4BYTE_KIND. Outside unicodeobject.c, you are not supposed >>> to see PyUnicode_WCHAR_KIND. >> >> Why do you say that? It can very well happen, assuming you call >> PyUnicode_KIND on a string that is not ready. That would be a >> bug in the module, but people do make bugs when programming. > > I added assert(PyUnicode_IS_READY(op)) to the macro, so the bug will be > quickly catched in debug mode. I forgot that it is just an assertion and > few people use Python compiled in debug mode. > >> If the rationale is to simplify silencing compiler errors, I >> vote for reverting the enumeration back to a macro list. > > I'm not sure that gcc will not complain if only 3 values are handled. I > agree to revert the commit if that helps developers to write bugs. It helps to detect bugs. User should be aware that there is an additional case, and put something like case PyUnicode_WCHAR_KIND: /* string is guaranteed to be ready here */ assert(0); into their code. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dict for Xmas?
On Fri, 16 Dec 2011 21:32:44 + Mark Shannon wrote: > > > per-instance attributes, it just forces them all to keep resizing up, > > even though individual instances would be small with the current dict. > There is a cut-off point, at the moment it's quite unsophisticated about > how it does this, but it could easily be improved. > Suggestions are welcome. Can you open an issue on the bug tracker? There you can either give your repo URL, or upload a patch. Both should allow to start reviewing the code :) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent script/console behaviour
Fernando Perez writes: > Apology for the advertising, If there's any apologizing to be done, it's on Anatoly's part. Your post was short, to the point, information-packed, and should put a big fat open-centered ideographic full stop period to this thread. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
