Mailman 3 June 2006 - Python-checkins

Re: [Python-checkins] r46472 - python/trunk/PCbuild8 python/trunk/PCbuild8/Uninstal.wse python/trunk/PCbuild8/_bsddb.vcproj python/trunk/PCbuild8/_ctypes.vcproj python/trunk/PCbuild8/_ctypes_test.vcproj python/trunk/PCbuild8/_elementtree.vcproj pytho
by Kristján V. Jónsson June 2, 2006

June 2, 2006

Hi there. Well, I was sort of hoping that it would "maintain itself" in an open source manner, but if it needs an official maintainter, we can do that. Particularly, we are interested in input from the community on how better to set up the projects in VS to perform the profile-guilded optimization step with minimal user input. Our current approach relies on a file called pythoncore_pgo_link.txt which needs to be manually updated when the project changes significantly. Martin, you have been doing work on getting python to be officially supported with VC 8. I remember that we discussed this at the pycon sprint. My VC8 build of 2.5 indeed did crash in the regression suite. I have some ideas on how to fix the C runtime problem. I will try some things locally and then bounce them off you and Tim. Cheers, Kristjan p.s. do you think I ought to subscribe to python-checkins? -----Original Message----- From: Tim Peters [mailto:tim.peters@gmail.com] Sent: 31. maí 2006 01:51 To: Martin v. Löwis; Kristján V. Jónsson Cc: kristjan.jonsson Subject: Re: [Python-checkins] r46472 - python/trunk/PCbuild8 python/trunk/PCbuild8/Uninstal.wse python/trunk/PCbuild8/_bsddb.vcproj python/trunk/PCbuild8/_ctypes.vcproj python/trunk/PCbuild8/_ctypes_test.vcproj python/trunk/PCbuild8/_elementtree.vcproj pytho [kristjan.jonsson] |>> Add a PCBuild8 build directory for building with Visual Studio .NET >> 2005. Contains a special project to perform profile guided >> optimizations on the pythoncore.dll, by instrumenting and running >> pybench.py [Martin v. Löwis] > Who is going to maintain that? I'm copying Kristján directly since I doubt he's still following the python-checkins list actively enough to notice that replies "to him" actually just go to python-checkins. Kristján is actively using that directory in his business, so he's maintaining it for now. At the NFS sprint he demonstrated significant speedups via exploiting profile-guided optimization, so it should of substantial interest over time. If everyone loses interest, fine, then it becomes like PC/VC6/ and RISCOS/ and ... in the meantime, it doesn't get in the way of anything I ever do <0.5 wink>.

5 5

r46598 - sandbox/branches/setuptools-0.6/ez_setup.py
by phillip.eby June 1, 2006

June 1, 2006

Author: phillip.eby Date: Thu Jun 1 22:04:16 2006 New Revision: 46598 Modified: sandbox/branches/setuptools-0.6/ez_setup.py Log: 0.6b2 MD5's Modified: sandbox/branches/setuptools-0.6/ez_setup.py ============================================================================== --- sandbox/branches/setuptools-0.6/ez_setup.py (original) +++ sandbox/branches/setuptools-0.6/ez_setup.py Thu Jun 1 22:04:16 2006 @@ -24,6 +24,8 @@ 'setuptools-0.6a11-py2.4.egg': 'a95d5bc7a070aa1028bc4dcb5270b133', 'setuptools-0.6b1-py2.3.egg': '8822caf901250d848b996b7f25c6e6ca', 'setuptools-0.6b1-py2.4.egg': 'b79a8a403e4502fbb85ee3f1941735cb', + 'setuptools-0.6b2-py2.3.egg': '5657759d8a6d8fc44070a9d07272d99b', + 'setuptools-0.6b2-py2.4.egg': '4996a8d169d2be661fa32a6e52e4f82a', } import sys, os

1 0

r46597 - peps/trunk/pep-3099.txt
by georg.brandl June 1, 2006

June 1, 2006

Author: georg.brandl Date: Thu Jun 1 20:49:59 2006 New Revision: 46597 Modified: peps/trunk/pep-3099.txt Log: Fold PEP 13 draft into PEP 3099. Modified: peps/trunk/pep-3099.txt ============================================================================== --- peps/trunk/pep-3099.txt (original) +++ peps/trunk/pep-3099.txt Thu Jun 1 20:49:59 2006 @@ -12,17 +12,47 @@ Abstract ======== -This PEP tries to list all BDFL pronouncements on Python 3000 that -refer to changes that will not happen and new features that will not -be introduced, sorted by topics, along with a short explanation or a -reference to the relevant thread on the python-3000 mailing list. +Some ideas are just bad. While some thoughts on Python evolution are +constructive, some go against the basic tenets of Python so +egregiously that it would be like asking someone to run in a circle: +it gets you nowhere, even for Python 3000, where extraordinary +proposals are allowed. This PEP tries to list all BDFL pronouncements +on Python 3000 that refer to changes that will not happen and new +features that will not be introduced, sorted by topics, along with +a short explanation or a reference to the relevant thread on the +python-3000 mailing list. + +If you think you should suggest any of the listed ideas it would be +better to just step away from the computer, go outside, and enjoy +yourself. Being active outdoors by napping in a nice patch of grass +is more productive than bringing up a beating-a-dead-horse idea and +having people tell you how dead the idea is. Consider yourself warned. Core language ============= +* ``self`` will not become implicit. + + Having ``self`` be explicit is a *good thing*. It makes the code + clear by removing ambiguity about how a variable resolves. It also + makes the difference between functions and methods small. + + Thread: "Draft proposal: Implicit self in Python 3.0" + http://mail.python.org/pipermail/python-dev/2006-January/059468.html + * ``lambda`` will not be renamed. + At one point lambda was slated for removal in Python 3000. + Unfortunately no one was able to come up with a better way of + providing anonymous functions. And so lambda is here to stay. + + But it is here to stay as-is. Adding support for statements is a + non-starter. It would require allowing multi-line lambda + expressions which would mean a multi-line expression could suddenly + exist. That would allow for multi-line arguments to function + calls, for instance. That is just plain ugly. + Thread: "genexp syntax / lambda", http://mail.python.org/pipermail/python-3000/2006-April/001042.html @@ -66,6 +96,20 @@ Thread: elimination of scope bleeding of iteration variables http://mail.python.org/pipermail/python-dev/2006-May/064761.html +* The parser won't be more complex than LL(1). + + Simple is better than complex. This idea extends to the parser. + Restricting Python's grammar to an LL(1) parser is a blessing, + not a curse. It puts us in handcuffs that prevent us from going + overboard and ending up with funky grammar rules like some other + dynamic languages that will go unnamed, like Perl. + +* No braces. + + This is so obvious that it doesn't need a reference to a mailing + list. Do ``from __future__ import braces`` to get a definitive + answer on this subject. + Builtins ========

1 0

r46596 - peps/trunk/pep-0360.txt
by david.goodger June 1, 2006

June 1, 2006

Author: david.goodger Date: Thu Jun 1 18:17:51 2006 New Revision: 46596 Modified: peps/trunk/pep-0360.txt Log: minor edits; use more appropriate markup for data records Modified: peps/trunk/pep-0360.txt ============================================================================== --- peps/trunk/pep-0360.txt (original) +++ peps/trunk/pep-0360.txt Thu Jun 1 18:17:51 2006 @@ -13,9 +13,9 @@ ======== There are many great pieces of Python software developed outside of -the Python standard library (aka, stdlib). Sometimes it makes sense -to incorporate these externally maintained packages into the stdlib in -order to fill a gap in the tools provided by Python. +the Python standard library (a.k.a., the "stdlib"). Sometimes it +makes sense to incorporate these externally maintained packages into +the stdlib in order to fill a gap in the tools provided by Python. But by having the packages maintained externally it means Python's developers do not have direct control over the packages' evolution and @@ -33,24 +33,25 @@ Externally Maintained Packages ============================== -The section title is the name of the package as known outside of the -Python standard library. The "standard library name" is what the +The section title is the name of the package as it is known outside of +the Python standard library. The "standard library name" is what the package is named within Python. The "contact person" is the Python -developer in charge of maintaining the package. The -"synchronisation history" lists what external version of the package -was included in each version of Python (if different from the previous -Python release). +developer in charge of maintaining the package. The "synchronisation +history" lists what external version of the package was included in +each version of Python (if different from the previous Python +release). ctypes ------ -- Web page + +:Web site: http://starship.python.net/crew/theller/ctypes/ -- Standard library name +:Standard library name: ctypes -- Contact person +:Contact person: Thomas Heller -- Synchronisation history +:Synchronisation history: * 0.9.9.6 (2.5) Bugs can be reported to either the Python tracker [#python-tracker]_ @@ -60,13 +61,14 @@ ElementTree ----------- -- Web page + +:Web site: http://effbot.org/zone/element-index.htm -- Standard library name +:Standard library name: xml.etree -- Contact person +:Contact person: Fredrik Lundh -- Synchronisation history +:Synchronisation history: * 1.2.6 [ElementTree] / 1.0.5 [cElementTree] (2.5) Patches should not be directly applied to Python HEAD, but instead @@ -77,27 +79,29 @@ Expat XML parser ---------------- -- Web page + +:Web site: http://www.libexpat.org/ -- Standard library name +:Standard library name: N/A (this refers to the parser itself, and not the Python bindings) -- Contact person +:Contact person: None -- Synchronisation history +:Synchronisation history: * 1.95.8 (2.4) * 1.95.7 (2.3) Optik ----- -- Web site + +:Web site: http://optik.sourceforge.net/ -- Standard library name +:Standard library name: optparse -- Contact person +:Contact person: Greg Ward -- Synchronisation history +:Synchronisation history: * 1.5.1 (2.5) * 1.5a1 (2.4) * 1.4 (2.3) @@ -105,13 +109,14 @@ pysqlite -------- -- Web site + +:Web site: http://www.sqlite.org/ -- Standard library name +:Standard library name: sqlite3 -- Contact person +:Contact person: Gerhard Häring -- Synchronisation history +:Synchronisation history: * 2.2.2 (2.5) Bugs should be reported to the pysqlite bug @@ -137,7 +142,6 @@ This document has been placed in the public domain. - .. Local Variables:

1 0

buildbot warnings in alpha Debian trunk
by buildbot＠python.org June 1, 2006

June 1, 2006

The Buildbot has detected a new failure of alpha Debian trunk. Full details are available at: http://www.python.org/dev/buildbot/all/alpha%2520Debian%2520trunk/builds/261 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: armin.rigo,georg.brandl,tim.peters Build Had Warnings: warnings test sincerely, -The Buildbot

1 0

r46595 - peps/trunk/pep-3100.txt
by david.goodger June 1, 2006

June 1, 2006

Author: david.goodger Date: Thu Jun 1 18:08:56 2006 New Revision: 46595 Modified: peps/trunk/pep-3100.txt Log: markup fix Modified: peps/trunk/pep-3100.txt ============================================================================== --- peps/trunk/pep-3100.txt (original) +++ peps/trunk/pep-3100.txt Thu Jun 1 18:08:56 2006 @@ -318,10 +318,10 @@ .. [27] python-3000 email ("sets in P3K?") http://mail.python.org/pipermail/python-3000/2006-April/001286.html - [28] python-3000 email ("sets in P3K?") +.. [28] python-3000 email ("sets in P3K?") http://mail.python.org/pipermail/python-3000/2006-May/001666.html - [29] python-3000 email ("bug in modulus?") +.. [29] python-3000 email ("bug in modulus?") http://mail.python.org/pipermail/python-3000/2006-May/001735.html .. [#pep238] PEP 238 (Changing the Division Operator)

1 0

r46594 - python/trunk/Objects/dictobject.c
by tim.peters June 1, 2006

June 1, 2006

Author: tim.peters Date: Thu Jun 1 17:50:44 2006 New Revision: 46594 Modified: python/trunk/Objects/dictobject.c Log: Armin committed his patch while I was reviewing it (I'm sure he didn't know this), so merged in some changes I made during review. Nothing material apart from changing a new `mask` local from int to Py_ssize_t. Mostly this is repairing comments that were made incorrect, and adding new comments. Also a few minor code rewrites for clarity or helpful succinctness. Modified: python/trunk/Objects/dictobject.c ============================================================================== --- python/trunk/Objects/dictobject.c (original) +++ python/trunk/Objects/dictobject.c Thu Jun 1 17:50:44 2006 @@ -227,24 +227,28 @@ contributions by Reimer Behrends, Jyrki Alakuijala, Vladimir Marangozov and Christian Tismer). -This function must never return NULL; failures are indicated by returning -a dictentry* for which the me_value field is NULL. Exceptions are never -reported by this function, and outstanding exceptions are maintained. +lookdict() is general-purpose, and may return NULL if (and only if) a +comparison raises an exception (this was new in Python 2.5). +lookdict_string() below is specialized to string keys, comparison of which can +never raise an exception; that function can never return NULL. For both, when +the key isn't found a dictentry* is returned for which the me_value field is +NULL; this is the slot in the dict at which the key would have been found, and +the caller can (if it wishes) add the <key, value> pair to the returned +dictentry*. */ - static dictentry * lookdict(dictobject *mp, PyObject *key, register long hash) { - register Py_ssize_t i; + register size_t i; register size_t perturb; register dictentry *freeslot; - register Py_ssize_t mask = mp->ma_mask; + register size_t mask = (size_t)mp->ma_mask; dictentry *ep0 = mp->ma_table; register dictentry *ep; register int cmp; PyObject *startkey; - i = hash & mask; + i = (size_t)hash & mask; ep = &ep0[i]; if (ep->me_key == NULL || ep->me_key == key) return ep; @@ -307,21 +311,20 @@ /* * Hacked up version of lookdict which can assume keys are always strings; - * this assumption allows testing for errors during PyObject_Compare() to - * be dropped; string-string comparisons never raise exceptions. This also - * means we don't need to go through PyObject_Compare(); we can always use - * _PyString_Eq directly. + * this assumption allows testing for errors during PyObject_RichCompareBool() + * to be dropped; string-string comparisons never raise exceptions. This also + * means we don't need to go through PyObject_RichCompareBool(); we can always + * use _PyString_Eq() directly. * - * This is valuable because the general-case error handling in lookdict() is - * expensive, and dicts with pure-string keys are very common. + * This is valuable because dicts with only string keys are very common. */ static dictentry * lookdict_string(dictobject *mp, PyObject *key, register long hash) { - register Py_ssize_t i; + register size_t i; register size_t perturb; register dictentry *freeslot; - register Py_ssize_t mask = mp->ma_mask; + register size_t mask = (size_t)mp->ma_mask; dictentry *ep0 = mp->ma_table; register dictentry *ep; @@ -343,10 +346,8 @@ if (ep->me_key == dummy) freeslot = ep; else { - if (ep->me_hash == hash - && _PyString_Eq(ep->me_key, key)) { + if (ep->me_hash == hash && _PyString_Eq(ep->me_key, key)) return ep; - } freeslot = NULL; } @@ -371,6 +372,7 @@ Internal routine to insert a new item into the table. Used both by the internal resize routine and by the public insert routine. Eats a reference to key and one to value. +Returns -1 if an error occurred, or 0 on success. */ static int insertdict(register dictobject *mp, PyObject *key, long hash, PyObject *value) @@ -412,14 +414,16 @@ known to be absent from the dict. This routine also assumes that the dict contains no deleted entries. Besides the performance benefit, using insertdict() in dictresize() is dangerous (SF bug #1456209). +Note that no refcounts are changed by this routine; if needed, the caller +is responsible for incref'ing `key` and `value`. */ static void insertdict_clean(register dictobject *mp, PyObject *key, long hash, PyObject *value) { - register Py_ssize_t i; + register size_t i; register size_t perturb; - register unsigned int mask = mp->ma_mask; + register size_t mask = (size_t)mp->ma_mask; dictentry *ep0 = mp->ma_table; register dictentry *ep; @@ -429,6 +433,7 @@ i = (i << 2) + i + perturb + 1; ep = &ep0[i & mask]; } + assert(ep->me_value == NULL); mp->ma_fill++; ep->me_key = key; ep->me_hash = (Py_ssize_t)hash; @@ -524,6 +529,16 @@ return 0; } +/* Note that, for historical reasons, PyDict_GetItem() suppresses all errors + * that may occur (originally dicts supported only string keys, and exceptions + * weren't possible). So, while the original intent was that a NULL return + * meant the key wasn't present, it reality it can mean that, or that an error + * (suppressed) occurred while computing the key's hash, or that some error + * (suppressed) occurred when comparing keys in the dict's internal probe + * sequence. A nasty example of the latter is when a Python-coded comparison + * function hits a stack-depth error, which can cause this to return NULL + * even if the key is present. + */ PyObject * PyDict_GetItem(PyObject *op, PyObject *key) { @@ -531,9 +546,8 @@ dictobject *mp = (dictobject *)op; dictentry *ep; PyThreadState *tstate; - if (!PyDict_Check(op)) { + if (!PyDict_Check(op)) return NULL; - } if (!PyString_CheckExact(key) || (hash = ((PyStringObject *) key)->ob_shash) == -1) { @@ -1607,8 +1621,8 @@ dict_has_key(register dictobject *mp, PyObject *key) { long hash; - register long ok; dictentry *ep; + if (!PyString_CheckExact(key) || (hash = ((PyStringObject *) key)->ob_shash) == -1) { hash = PyObject_Hash(key); @@ -1618,8 +1632,7 @@ ep = (mp->ma_lookup)(mp, key, hash); if (ep == NULL) return NULL; - ok = ep->me_value != NULL; - return PyBool_FromLong(ok); + return PyBool_FromLong(ep->me_value != NULL); } static PyObject * @@ -1932,6 +1945,7 @@ {NULL, NULL} /* sentinel */ }; +/* Return 1 if `key` is in dict `op`, 0 if not, and -1 on error. */ int PyDict_Contains(PyObject *op, PyObject *key) { @@ -1946,9 +1960,7 @@ return -1; } ep = (mp->ma_lookup)(mp, key, hash); - if (ep == NULL) - return -1; - return ep->me_value != NULL; + return ep == NULL ? -1 : (ep->me_value != NULL); } /* Hack to implement "key in dict" */

1 0

r46593 - sandbox/branches/setuptools-0.6/EasyInstall.txt
by phillip.eby June 1, 2006

June 1, 2006

Author: phillip.eby Date: Thu Jun 1 17:39:04 2006 New Revision: 46593 Modified: sandbox/branches/setuptools-0.6/EasyInstall.txt Log: Add missing 0.6b2 release note Modified: sandbox/branches/setuptools-0.6/EasyInstall.txt ============================================================================== --- sandbox/branches/setuptools-0.6/EasyInstall.txt (original) +++ sandbox/branches/setuptools-0.6/EasyInstall.txt Thu Jun 1 17:39:04 2006 @@ -1103,6 +1103,8 @@ * Construct ``.pth`` file paths in such a way that installing an egg whose name begins with ``import`` doesn't cause a syntax error. + * Fixed a bogus warning message that wasn't updated since the 0.5 versions. + 0.6b1 * Better ambiguity management: accept ``#egg`` name/version even if processing what appears to be a correctly-named distutils file, and ignore ``.egg``

1 0

buildbot warnings in x86 Ubuntu dapper (icc) trunk
by buildbot＠python.org June 1, 2006

June 1, 2006

The Buildbot has detected a new failure of x86 Ubuntu dapper (icc) trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%2520Ubuntu%2520dapper%2520%2528i… Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: tim.peters Build Had Warnings: warnings test sincerely, -The Buildbot

1 0

buildbot warnings in hppa Ubuntu dapper trunk
by buildbot＠python.org June 1, 2006

June 1, 2006

The Buildbot has detected a new failure of hppa Ubuntu dapper trunk. Full details are available at: http://www.python.org/dev/buildbot/all/hppa%2520Ubuntu%2520dapper%2520trunk… Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: armin.rigo,georg.brandl Build Had Warnings: warnings test sincerely, -The Buildbot

1 0