Mailman 3 January 2007 - Python-Dev

Code working in both 2.x and 3.X
by Jim Jewett 11 Jan '07

11 Jan '07

Raymond Hettinger wrote: > Also, I'm wondering if the desire for 2.6 warnings is based on the notion that > it will be possible to get large tools to work under both Py2.x and Py3.x. I had certainly assumed it would be possible. In fact, I had assumed that the 2->3 translator would have a mode which left the code running in both. This might not be the cleanest possible code for either line (parens in 2.x, some extra iter calls or missed shortcuts, etc), but it should certainly exist. If it doesn't, then people who do want to support both lines will themselves have to work exclusively in 2.x and "compile" to 3.x. > With all the module renaming/packaging, I had believed that 2.x would support both names, typically as >>> # make an deprecation warning, or log entry >>> from oldname import * So code using the new names may not work in 2.5, but should work in 2.6. If you want it to work in 2.3, you either use conditional imports or include your own forwarding modules for older pythons. > old-style classes disappearing, This is only a problem if you rely on specfically old-style semantics. Most old-style classes that I see work fine as new-style; the author just didn't want to put in the extra boilerplate (or wanted 1.5 compatibility, or just didn't bother to make a change). > encoded text objects, This one I'm less sure about, but it seems that programs which work correctly with both str and unicode in 2.x should work with 3, and that programs which (in practice) restrict themselves to ASCII will continue to work. > real division You can already get this a __future__ import, and you can explicitly request the old form (in both lines) by truncating the result. > and whatnot; that notion may be a pipe-dream. I hope not. That said, I'm not so sure about C extension modules... -jJ

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by Anthony Baxter 11 Jan '07

11 Jan '07

On Thursday 11 January 2007 06:32, Georg Brandl wrote: > I guess there are quite a few people who won't start moving to > Python 3.0 with 2.6, or even when 3.1 is out, as long as their > program works fine with the 2.x line. There's no need to punish > them with extra overhead. Checking a single C global int is hardly going to make a huge impact at all. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by Phillip J. Eby 11 Jan '07

11 Jan '07

At 11:10 PM 1/10/2007 +0000, Paul Moore wrote: >On 10/01/07, glyph(a)divmod.com <glyph(a)divmod.com> wrote: > > I've been assuming for some time that the only hope for Py3k compatibility > > within Twisted would be using PyPy as a translation layer. > >Does this ring as many warning bells for me as it does for others? I >know very little about the current state of PyPy, but I read your >comment as implying that you expect Twisted to be unavailable (at some >level or other) for users of Py3K. Is that right? > >How many other projects/packages anticipate *not* migrating to Py3K, I wonder? I think it's safe to say that any package of comparable size is going to think twice about it without transitional compatibility.

1 0

python-ideas on gmane
by Georg Brandl 11 Jan '07

11 Jan '07

Hi, is there any objection against making python-ideas available on gmane? Should I just suggest it myself, or has someone to do extra admin work on the mailing list side? Georg

3 2

Re: [Python-Dev] [Python-3000-checkins] r53335 - in python/branches/p3yk: Doc/Makefile.deps Doc/lib/lib.tex Doc/lib/libsets.tex Doc/lib/libstdtypes.tex Lib/msilib/__init__.py Lib/sets.py Lib/test/test_cookielib.py Lib/test/test_set.py Lib/test/test_sets.py
by Guido van Rossum 10 Jan '07

10 Jan '07

On 1/9/07, Brett Cannon <brett(a)python.org> wrote: > Should we bother with deprecating 'sets' in the 2.x series? I'd say so, yes. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

DRAFT: pydev summary for 2006-12-01 to 2006-12-15
by Calvin Spealman 09 Jan '07

09 Jan '07

============= Announcements ============= Some of you may know that Steven Bethard, having taken over the summaries from Brett Cannon some time ago, is no longer able to keep up with them. After much holiday stress and busy days, I've come to take over this honor and archive all the goings on here. I hope I can do a good job, and allow the summaries to continue being a useful and transparent fixture. Also, after catching up with my backlog of summary work, I plan to begin the first summaries of python-3000 (and, possibly, but not likely, the python- ideas list), as more and more actual work, rather than debating and theory-talk, is going on there. Sincerly, Your new summary writer, Calvin Spealman ========= Summaries ========= ----------------------------------------------------------------------------- [NPERS] Re: a feature i'd like to see in python #2: indexing of match objects ----------------------------------------------------------------------------- Subscripting re match objects directly was proposed and the debate the waged mostly on how to deal with slicing and m.group(0) to be the entire match. The consensus seemed to be that returning a match object would break, largely because m[1:2][0] != m[1], which breaks intuition with slices. Returning a list as a slice also breaks the intuitions about the type of a slice. Contributing thread: - `a feature i'd like to see in python #2: indexing of match objects <http://mail.python.org/pipermail/python-dev/2006-December/070138.html>`__ ---------------------------------------- Python and the Linux Standard Base (LSB) ---------------------------------------- Discussions about how to properly document the expected Python environment for all LSB compliant distributions continued shortly. Focus was on how distros have a need to split the standard library up, even if the entire thing is eventually installed, and issues such as Tkinter requiring X leading to standard modules being ommitted for flexable packages. Contributing thread: - `Python and the Linux Standard Base (LSB) <http://mail.python.org/pipermail/python-dev/2006-December/070112.html>`__ ---------------------------------------------------------------------- [Python-checkins] MSI being downloaded 10x more than all other files?! ---------------------------------------------------------------------- Guido was impressed with out download numbers on Windows, but most people just attributed it to other platforms including and mirroring Python. Even taking that to consideration, the ratio of Windows to source downloads has shifted in Windows favor a good bit. The use of Python in introductory courses at MIT was mentioned as something to push these numbers further in the near future. Contributing thread: - `[Python-checkins] MSI being downloaded 10x more than all other files?! <http://mail.python.org/pipermail/python-dev/2006-December/070294.html>`__ ---------------------------------------------------------------- a feature i'd like to see in python #1: better iteration control ---------------------------------------------------------------- The request was made to allow direct deletion of items from iterables through the iterator, but the idea was deemed unscalable to iterables in general and broken with dictionaries. The solutions to work around the problem were given and generally agreed to be sufficient (such as copying all the items you want to keep, instead). Contributing thread: - `a feature i'd like to see in python #1: better iteration control <http://mail.python.org/pipermail/python-dev/2006-December/070137.html>`__ ------------------------- LSB: Binary compatibility ------------------------- The other side of the LSB issue was discussed, related to the CPython ABI, the .pyc bytecode and the marshall formats, and exactly which versions of Python may or may not gain a standard ABI, as well as how to carry this forward to future (already existing and evolving) version of Python. Some mention was made of the difficulties and conflicts being brought on by the idea of LSB standards for Python, while the benefits of this were challenged. Contributing thread: - `LSB: Binary compatibility <http://mail.python.org/pipermail/python-dev/2006-December/070191.html>`__ ---------------------------------------- Adding resume (206) support to urllib(2) ---------------------------------------- Daniel Watkins asked about adapting his HTTP resuming support into urllib, but suggestions directly moved this to urllib2 and then to httplib. The conversation quickly drifted into talking about how abstract and minimal the urllib(2) should be, while the httplib module may grow increasing complex and feature supporting. The original poster made no final comment on his intentions to follow through with the patch. Contributing thread: - `Adding resume (206) support to urllib(2) <http://mail.python.org/pipermail/python-dev/2006-December/070320.html>`__ ------------------- __str__ and unicode ------------------- The details of what an object's __str__() method must return were inquired. Must the string returned by a str or any basestring? It was announced to allow unicode objects, with no restriction on content. However, the caution that the return is likely to be encoded into the default encoding was given. Contributing thread: - `__str__ and unicode <http://mail.python.org/pipermail/python-dev/2006-December/070237.html>`__ ---------------------------------- LSB: Selection of a Python version ---------------------------------- Martin v. Lowis announced that LSB will likely move forward with Python 2.4 as the first LSB standard Python version. How to handle future bug patches, as well as the comfort of the distributions for being required to support an outdated package (2.4 is already "retired") was considered. The consensus settled on a documented support for 2.4 moving forward with security patches, and likely even 2.3, as security patches are rare enough to not cause too many cycles to be spent on them. Contributing thread: - `LSB: Selection of a Python version <http://mail.python.org/pipermail/python-dev/2006-December/070189.html>`__ ------------------------------ Threading, atexit, and logging ------------------------------ A bug (#1566280) was previously reported, related to the ordering of the atexit handlers for the logging and threading modules. Participants in the thread had a general agreement that the threading module using such a user visiable mechanism for cleanup and lifetime was a bad design in the first place to be remedied. Contributing thread: - `Threading, atexit, and logging <http://mail.python.org/pipermail/python-dev/2006-December/070233.html>`__ ----------------------------------- Creating dicts from dict subclasses ----------------------------------- A common problem of subclassing built-in types (dict, in this case) arose trying to move weakref.WeakValueDictionary to a subclass of dict, rather than UserDict. [NOTE: Could someone give a better description of this? I don't know enough of the issue here to write any content full enough. Thanks.] Contributing thread: - `Creating dicts from dict subclasses <http://mail.python.org/pipermail/python-dev/2006-December/070334.html>`__ ----------------------------------------------------------------------------- OT: World's oldest ritual discovered. Worshipped the python 70, 000 years ago ----------------------------------------------------------------------------- This was a quick and off-topic post about other instances of python symbolism in ancient humanity, including a definition of our word "pythonic" to mean "prophetic", which seems fitting enough. Contributing thread: - `OT: World's oldest ritual discovered. Worshipped the python 70, 000 years ago <http://mail.python.org/pipermail/python-dev/2006-December/070123.html>`__ ------------------ LSB: pyc stability ------------------ The LSB meetings brought up the issue of standardized bytecode formats, again. This has always been something discouraged from Python. Keeping the bytecode format free and the implementation open to ignoring old versions, has always been helpful for maintanence and development. The common reasoning of protecting IP was used, although most in-the-know consider this to be a false sense of security. Reguardless, it might be useful in legal ways, as trade secrets do require a reasonable attempt at hidding them in order to be recognized as such. The possible solution of importing encypted zip packages with a custom import hook was proposed and seems logical. Contributing thread: - `LSB: pyc stability <http://mail.python.org/pipermail/python-dev/2006-December/070187.html>`__ ---------------------------------------------------------------------- features i'd like [Python 3000?] ... #4: interpolated strings ala perl ---------------------------------------------------------------------- Perl/PHP style string interpolation was brought up, but is found unreasonable for various reasons. Cons include the use of format strings in scopes outside where they are defined, the dangers of eval, and possibly the general resisting of any idea coming from Perl. This seems a highly unlikely proposal. Contributing thread: - `features i'd like [Python 3000?] ... #4: interpolated strings ala perl <http://mail.python.org/pipermail/python-dev/2006-December/070173.html>`__ --------------------------- Polling with Pending Calls? --------------------------- Issues with the RPM library blocking interupts for long periods of time were brought up with proposed fixes by patching the rpmlib bindings to "automagically" poll for any pending calls. An existing patch was suggested but did not seem to fit the case at hand. Contributing thread: - `Polling with Pending Calls? <http://mail.python.org/pipermail/python-dev/2006-December/070181.html>`__ =============== Skipped Threads =============== - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-December/070119.html>`__ - `cross-compile patches <http://mail.python.org/pipermail/python-dev/2006-December/070216.html>`__ - `Windows SDK <http://mail.python.org/pipermail/python-dev/2006-December/070308.html>`__ - `help for a noob - version for a sharp ARM <http://mail.python.org/pipermail/python-dev/2006-December/070286.html>`__ - `fileinput module tests <http://mail.python.org/pipermail/python-dev/2006-December/070307.html>`__ - `Open CPython VM for type information <http://mail.python.org/pipermail/python-dev/2006-December/070328.html>`__ - `fpectl: does a better implementation make sense? <http://mail.python.org/pipermail/python-dev/2006-December/070118.html>`__ - `Small tweak to tokenize.py? <http://mail.python.org/pipermail/python-dev/2006-December/070127.html>`__ - `features i'd like [Python 3000] ... #3: fix super() <http://mail.python.org/pipermail/python-dev/2006-December/070168.html>`__ - `Makefile.pre.in Patch <http://mail.python.org/pipermail/python-dev/2006-December/070172.html>`__ - `Python and LSB: Meeting Report <http://mail.python.org/pipermail/python-dev/2006-December/070186.html>`__ - `Virtual Python (was Re: Python and the Linux Standard Base (LSB)) <http://mail.python.org/pipermail/python-dev/2006-December/070194.html>`__ - `DRAFT: python-dev summary for 2006-11-16 through 2006-11-30 <http://mail.python.org/pipermail/python-dev/2006-December/070229.html>`__ - `Looking for new Python-Dev Summarizers <http://mail.python.org/pipermail/python-dev/2006-December/070232.html>`__ - `Adding C99 bool to struct module <http://mail.python.org/pipermail/python-dev/2006-December/070276.html>`__ - `Spam and semi-spam and neo-spam <http://mail.python.org/pipermail/python-dev/2006-December/070284.html>`__ - `[NPERS] Re: a feature i'd like to see in python #1: betteriteration control <http://mail.python.org/pipermail/python-dev/2006-December/070171.html>`__ - `Next PyPy sprint: Leysin 8-14th January 2007 <http://mail.python.org/pipermail/python-dev/2006-December/070217.html>`__ - `Distribution tools: What I would like to see <http://mail.python.org/pipermail/python-dev/2006-December/070234.html>`__ - `RealClearPolitics - Articles - Exit Rumsfeld, Smiling <http://mail.python.org/pipermail/python-dev/2006-December/070283.html>`__

2 1

Apologies from the CBS autoresponder
by Tim Golden 09 Jan '07

09 Jan '07

My many apologies to those who had their New Year interrupted by my company's inane autoresponder. I'm afraid that I went on leave for a week without suspending list delivery just as my company changed its name and sent out (unknown to me) an automatic message to *everything* coming in to the old address. I've pulled the plug on that address's subscription, altho' I suspect some list admin got there before me. Apologies again. Tim Golden

1 0

Bug or not? Different behaviour iterating list and collections.deque
by Christos Georgiou 08 Jan '07

08 Jan '07

Hello, people. I am not sure whether this is a bug or intentional, so I thought checking it with you before opening a bug. I will explain this issue, but please understand this is not a question for help to change the algorithm (this has been done already), so it's not a question of c.l.py. It's a matter of discrepancy. A list that changes while iterating produces no errors, while a deque fails. Given the following example code: #code start import itertools, collections def item_is_special(item): "Just a dummy check in this example" return item % 3 == 0 def item_products(item): "Also a dummy function for the example" return [item*20+1, item*30+1] def process_list(items, type_of_que, special_case): # we want to process some items, but some of them # produce other items to be processed by the # same algorithm products= type_of_que() if special_case: products.append(-1) for item in itertools.chain(items, products): if item_is_special(item): for product in item_products(item): products.append(product) else: print "got", item #code end we have the following cases: >>> process_list(numbers, list, False) got 1 got 2 got 61 got 91 List works as expected. >>> process_list(numbers, collections.deque, False) got 1 got 2 deque does not work, most probably because deque.__iter__ of an empty deque ignores later changes. For this reason the `special_case' parameter was inserted in the code above, so that there is at least an item when itertools.chain calls iter on the deque: >>> process_list(numbers, collections.deque, True) got 1 got 2 Traceback (most recent call last): File "<stdin>", line 1, in <module> File "testdequeiter.py", line 17, in process_list for item in itertools.chain(items, products): RuntimeError: deque mutated during iteration Is that intentional? If not, let me know so that I open a bug.

4 6

Re: [Python-Dev] Pydoc Improvements / Rewrite
by Laurent Gautier 08 Jan '07

08 Jan '07

Ron, I agree that pydoc could benefit a bit from some cleanup. As you point it out, the ability to write quick viewers would be very helpful. I came across that when wanting to develop script on a remote web server for which I only had FTP access: I ended up having to study pydoc more than I wanted in order to be able to build a display-the-doc cgi. However having two different modules might not be needed. Introspection is probably already available in the separate module 'inspect', and what a code pydoc would have to do is model the documentation (as a tree) and offer convenience function to navigate the data. Beside that, there would be sub-modules for the different viewers for the documentation data - the interactive console being just one of the viewers. Finally, I would suspect that an API-breaking modification of the module would need time to be accepted. May be the original author of pydoc is considering changes as well, and joining effort would be possible ? L. PS: I would also not go for a module name deliberately prefixed with "_" (as some people might associate that with protected or private objects).

9 19

Pydoc Improvements / Rewrite
by Ron Adam 08 Jan '07

08 Jan '07

I started to discuss this on the new python-ideas list because I thought it may need a bit more completion before bringing it here. But It was suggested that it really does belong here as it is something that would be nice to have in python 2.6. So I'm reposting the introduction here. The still very rough source files can be downloaded from: http://ronadam.com/dl/_pydoc.zip There is still much to do, but I think having some experienced feed back on where it should go is important. Cheers, Ron Adam ps.. Please disregard the website for now, it's purpose was to share with family and friends, although I will probably share the python source to the ledger program there and other python toys and experiments (for fun) in the near future. [Introduction From python-ideas list] Improving pydoc has been suggested before by me and others. I've been working on a version that is probably 80% done and would like to get feed back at this point to determine if I'm approaching this in the best way. Basically pydoc.py consists of over 2,000 lines of python code and is not well organized inside which means (my thoughts) it will pretty much stay the way it is and not be as useful as it could be. Currently pydoc.py has the following uses. * It is imported and used as pythons console help function. * It can be used to generate help text files. * It can open a tkinter search index and from that launch a web server and a browser to veiw a html help page. * It can be used to generate static html help files. It looks (to me) like splitting it into two modules would be good. One module for just the text help and introspection functions, and the other for the html server and html output stuff. [It was suggested on python-ideas that making it a package may be good.] 1. pyhelp.py - Pythons help function from inside the console, and running it directly would open an interactive text help session. 2. _pydoc.py - Python html help browser. This starts an html server and opens a web page with a modules/package index. The html page headers would contain the current Python version info and the following inputs fields. * get field - directly bring up help on an object/module/or package. * Search field - returns a search results index. * Modules button - modules index page * Keywords button - keywords index page * Help button - pydoc Help instructions, version, and credits info. Note: The leading underscore "_pydoc.py" is to keep it from clashing with the current pydoc version. It probably should be something else. An additional feature is clicking on a filename opens up a numbered source listing. Which is nice for source code browsing and for referencing specific lines of code in python list discussions. ;-) The colors, fonts and general appearance can be changed by editing the style sheet. The output is readable as plain (outline form) text if the style sheet is ignored by the browser. _pydoc.py imports pyhelp and uses it to do the introspection work and extends classes in pyhelp to produce html output. I've tried to make pyhelp.py useful in a general way so that it can more easily be used as a base that other output formats can be built from. That's something that can't be done presently. These improvements to pydoc mean you can browse pythons library dynamically without ever leaving the web browser. Currently you switch back and forth between the browser and a tkinter index window. Something I found to be annoying enough to discourage me from using pydoc. The version I'm working on is split up into eight python files, each addressing a particular function of pydoc. That was to help me organize things better. These will be recombined into fewer files. Some parts of it could be moved to other modules if they seem more generally useful. For example, the console text pager could be used in many other console applications. Things that still need to be done are adding the object resolution order output back in. And adding inter-page html links back in. And a few other things I just haven't gotten to yet. I got a bit burned out on this project a while back, and then moved to a new house.. etc.. etc.. But I'm starting to have more time, and with the current discussion s turning on to refining pythons library this seems like it would be a useful tool in that effort. Any comments on this general approach? Any suggestions, questions, or comments? I'll post a link to the zipped files in the next day or two and announce it here. I need to look into a glitch on my computer first that's probably a windows path/name problem. I don't think it's anything that needs to be fixed in the files but I want to be sure. Cheers, Ron Adam

9 13