Mailman 3 November 2010 - Python-Dev

PEP 3151 dictator
by Antoine Pitrou 17 Nov '10

17 Nov '10

Hello, I would like to announce that, following Guido's (private) suggestion that I find a temporary dictator for PEP 3151, Barry has accepted to fill in this role. Regards Antoine.

1 0

new LRU cache API in Py3.2
by Stefan Behnel 17 Nov '10

17 Nov '10

Hi, reading the description of the new LRU cache in the "What's new in 3.2" document now, I got the impression that the hits/misses attributes and the .clear() method aren't really well namespaced. When I read get_phone_number.clear() it's not very obvious to me what happens, unless I know that there actually *is* a cache involved, which simply has the same name as the function. So this will likely encourage users to add a half-way redundant comment like "clear the cache" to their code. What about adding an intermediate namespace called "cache", so that the new operations are available like this: print get_phone_number.cache.hits get_phone_number.cache.clear() ? It's just a little more overhead, but I think it reads quite a bit better. Stefan

7 8

Help deploying a new buildbot running OpenIndiana/x86
by Jesus Cea 17 Nov '10

17 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, everybody. I am glad to say I am installing an OpenIndiana zone (Openindiana is a fork of Indiana, a distribution of OpenSolaris) with the aim to be a buildbot for python development. This machine has plenty of disk (even SSD!), CPU and memory for the task. I am reading http://wiki.python.org/moin/BuildBot . I have installed buildbotslave already, but I need passwords, etc., to link to python buildbot infraestructure. The machine is behind a NAT system, so any incoming connection will need to be documented and a port mapping request to be done. So, after installing buildbotslave, what is the next step?. Thanks to OpenIndiana staff, specially Alasdair Lumsden, for providing the physical resources for this attempt. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTOP9pplgi5GaxT1NAQLmWQP6AqEGqEX3b50qKTP2MrkJwYQ8pXCOJm+6 fGB4jpH+i47mzgSOtANvrp1N5qOmHXzjbdWlVrL2/7ZOeLiGWSnq/ZvpTrYaysU3 o2zG4rhk48jsSYE7u0EoSKk272LmAiTU6WBSt6ZMzOGWIQxdjMhs/OVanpFybBc0 rCbATfdJ3hQ= =rIqM -----END PGP SIGNATURE-----

3 5

I need help with IO testuite
by Jesus Cea 17 Nov '10

17 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I am modifying IO module for Python 3.2, and I am unable to understand the mechanism used in IO testsuite to test both the C and the Python implementation. In particular I need to test that the implementation passes some parameters to the OS. The module uses "Mock" classes, but I think "Mock" is something else, and I don't see how it interpose between the C/Python code and the OS. If somebody could explain the mechanism a bit... Thanks for your time and attention. Some background: http://bugs.python.org/issue10142 - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTOPnJplgi5GaxT1NAQLVqQP/cf9+hdLdoSMzY+cSquq7YZMiQOQ0aMEH ZRn+su4F3qg5e8MgEQOXFj9uGEjVDLwonE4nBZ+T3ovBcPCyGaLB/K/YttZGVM5/ O3gpzZss9bkMvuWQCblyEJp8uzJC831AwPDMg1Q0nbMiTnJlW5dY1CX9BD0gYPBW oIVBt2oBfCI= =hq7M -----END PGP SIGNATURE-----

3 3

python3k vs _ast
by Emile Anclin 17 Nov '10

17 Nov '10

hello everybody, migrating Pylint to python3.x, we encounter a little problem : in the tree generated by _ast, if we consider a "args" node (representing an argument of a function), the "lineno" (and the "col_offset") information disappeared from those nodes. Is there a particular reason for that ? In python2.x, the "args" nodes were just "Name" nodes, and as for now we keep them as "AssName" nodes in astng/pylint and would like to know where it was defined. thx for any information -- Emile Anclin <emile.anclin(a)logilab.fr> http://www.logilab.fr/ http://www.logilab.org/ Informatique scientifique & et gestion de connaissances

4 5

Proposed adjustments to PEP 0 generation
by Nick Coghlan 17 Nov '10

17 Nov '10

The lists of Meta-PEPs and Other Informational PEPs at the beginning of PEP 0 are starting to get a little long, and contain some outdated information that doesn't really deserve pride of place at the top of the PEP index. If I don't hear any objections in this thread, I plan to make the following tweaks to the PEP 0 generator "soonish": - make these two lists respect the "Withdrawn" and "Rejected" flags (i.e. taking the relevant PEPs out of this list and dropping them into later categories) - adding a new "Historical" category for PEPs that have served their purpose and are no longer of immediate interest (primarily old release PEPs, but also the old SVN migration PEP, the DVCS study and PEP 42) Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Python bug week-end : 20-21 November
by Antoine Pitrou 16 Nov '10

16 Nov '10

Hello, The development team of the Python interpreter (a.k.a python-dev) is organizing a bug week-end on Saturday 20th and Sunday 21st of November. We would like to encourage anyone who feels interested in participating to give it a try. Contributing to Python is much less intimidating than it sounds. You don't need to have previous experience with modifying the Python source; in fact bug days offer a good opportunity to learn the basics by asking questions and working on relatively simple bugs (see "how to get prepared" below). And most core developers are actual human beings! How it happens -------------- The bug week-end will happen on the #python-dev IRC channel on the Freenode network, where several core developers routinely hang out. No physical meeting is scheduled as far as I know, but anyone is encouraged to organize one and announce it on the official Python channels such as this one. Participants (you!) join #python-dev and collaboratively go through the Python issue tracker at http://bugs.python.org . From there, you can provide patches and/or review existing patches. Also, you can help us assess issues on any specific topic you have expertise in (the range of topics touched in the stdlib is quite broad and it is more than likely that the core developers' expertise is lacking in some of them). Or, if you feel shy, you can simply watch other people work and slowly get more confident about participating yourself. Development is public and lurkers are welcome. What you can work on --------------------- Our expectation is that Python 3.2 beta 1 will have been released a couple of days before the bug week-end and, therefore, one primary goal is to polish the 3.2 branch for the following betas and the final release. There are many issues to choose from on the bug tracker; any bug fixes or documentation improvements will do. New features are discouraged: they can't be checked in before the official 3.2 release. How to get prepared ------------------- If you are a beginner with the Python codebase, you may want to read the development guide available here (courtesy of Brian Curtin): http://docs.pythonsprints.com/core_development/beginners.html There's a small practical guide to bug days/week-ends on the wiki: http://wiki.python.org/moin/PythonBugDay And the development FAQ holds answers to generic development questions: http://www.python.org/dev/faq/ You can also do all of the above during the bug week-end, of course. Please, don't hesitate to ask us questions on the #python-dev channel. Regards Antoine.

4 4

PyUnicode_GetMax() and PyUnicode_FromOrdinal() Was: Breaking undocumented API
by Alexander Belopolsky 16 Nov '10

16 Nov '10

On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg <mal(a)egenix.com> wrote: > Alexander Belopolsky wrote: >> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg <mal(a)egenix.com> wrote: >> .. >>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has >>> to be available as callable in order to applications or extensions >>> to use it (without recompile). >>> >> >> .. but it *is* a macro resolving to either PyUnicodeUCS2_GetMax or >> PyUnicodeUCS4_GetMax. > > That doesn't count :-) It's only a trick to prevent external code > from using the wrong Unicode APIs. > > There still is a real function behind the renaming. > >> What is the scenario when may want to change >> what PyUnicodeUCS?_GetMax return and have extensions pick up the >> change without a recompile? > > If an extensions uses the stable ABI, it will want to know > whether the interpreter was built for UCS2 or UCS4 (even if > it doesn't use the Unicode APIs directly). > >> UCS2 case will certainly never change >> since it is already 0xFFFF. Is it possible that USC4 will be expanded >> beyond 0x10FFFF? > > Well, the Unicode Consortium decided to not go beyond 0x10FFFF, > but then you never know... when they started out on the quest, > 16 bits appeared more than enough, but they found out relatively > quickly that the Asian scripts had enough code points to easily > fill that space. > > Once space is available, it tends to get used sooner or later :-) > >> Note that we can have both a macro and a function >> version. This is fairly standard practice in Python C-API. > > Sure, but what for ? Note that PyUnicode_FromOrdinal() is documented (in unicodeobject.h) as follows without a reference to PyUnicode_GetMax(): """ Create a Unicode Object from the given Unicode code point ordinal. The ordinal must be in range(0x10000) on narrow Python builds (UCS2), and range(0x110000) on wide builds (UCS4). A ValueError is raised in case it is not. """ The actual implementation actually checks UCS4 range only. if (ordinal < 0 || ordinal > 0x10ffff) { PyErr_SetString(PyExc_ValueError, "chr() arg not in range(0x110000)"); return NULL; } This actually looks like a bug: >>> len(chr(0x10FFFF)) 2 (on a USC2 build.) Also, I think PyUnicode_FromOrdinal() should take Py_UNICODE argument rather than int.

2 2

Re: [Python-Dev] [RELEASED] Python 3.2 alpha 4
by Paul Moore 16 Nov '10

16 Nov '10

(Copying to the list, sorry Georg for the duplicate) On 16 November 2010 14:05, Georg Brandl <georg(a)python.org> wrote: > On behalf of the Python development team, I'm happy to announce the > fourth and (this time really) final alpha preview release of Python 3.2. PEP 3148 (Futures) is noted in the PEP as going into 3.2, It also seems to be in the release. Should it not be added to the "What's new in 3.2" document and the release announcements? It's a fairly significant feature. Paul.

2 2

[RELEASED] Python 3.2 alpha 4
by Georg Brandl 16 Nov '10

16 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the fourth and (this time really) final alpha preview release of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * an overhauled GIL implementation that reduces contention * many consistency and behavior fixes for numeric operations * countless fixes regarding string/unicode issues; among them full support for a bytes environment (filenames, environment variables) * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger For an extensive list of changes in 3.2, see Misc/NEWS in the Python distribution. To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ 3.2 documentation can be found at: http://docs.python.org/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzij74ACgkQN9GcIYhpnLCbtwCgi4whRruM0Oi6yfgjVclYErFa OJcAn0U8UBBsQBFyGcnKJRbls6B+guQ2 =Vuqf -----END PGP SIGNATURE-----

1 0