Mailman 3 July 2004 - Python-Dev

Re: [Python-Dev] VC 7.1 maintenance?
by Jack Jansen 05 Jul '04

05 Jul '04

On 16 Jun 2004, at 22:46, Tim Peters wrote: > [M.-A. Lemburg] >> Are we going to have a VC7.1 binary of Python 2.4 for Windows ? > > That's indeed my understanding of The Plan today. More, we will not > have a > VC6 binary for Python 2.4. That may be controversial, but nobody has > volunteered to produce an installer for a VC6 version. Does this mean that the final answer to the question of whether VC7 was GPL-compatible was "yes"? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

7 17

Leading whitespace in Mac IDE script name
by Nick Coghlan 04 Jul '04

04 Jul '04

Hi, I'm trying to fetch Python from CVS using Eclipse, and it's choking on a file with leading whitespace in its name: /python/dist/src/Mac/IDE scripts/Widget demos/ separator --- There's an identical file in the same directory, but without the leading whitespace in the name. So is this 'leading whitespace' version actually needed, or is it something historical? Regards, Nick P.S. I also sent a question to the Eclipse folks regarding the fact that the Eclipse CVS checkout collapses in a screaming heap when it hits this file. However, if the Mac release doesn't use this file, getting rid of it from the HEAD would probably get me up and running more quickly. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

3 3

RE: [Python-Dev] PEP 276 (simple iterator for ints)
by Delaney, Timothy C (Timothy) 04 Jul '04

04 Jul '04

Andrew Koenig wrote: > for i in myList.keys(): > > would be even better, because it allow the same usage for dict and > list. Of course that wouldn't generalize to other sequences that > support len. Hmm - time to propose a new builtin (can't remember this being proposed before, though I know we've discussed adding keys() to lists). keys(mapping) Returns an iterator of the keys of the mapping. For any sequence that implements __len__, returns an iterator of the integers 0..__len__. For any object that implements keys() or iterkeys(), returns the appropriate iterator. I would also suggest that __keys__ might be a useful magic method. There might be a use for values(mapping) as well, but I don't think it's as useful. Tim Delaney

1 0

RE: [Python-Dev] VC 7.1 maintenance? [getting OT]
by Delaney, Timothy C (Timothy) 04 Jul '04

04 Jul '04

John J Lee wrote: > On Thu, 1 Jul 2004, Tim Peters wrote: > [...] >> It's possible (don't know) that InnoSetup doesn't play "correctly" >> with XP system restore points. MSI does. I've found restore points >> to be an essentially useless feature, so I don't really care about >> that. > [...] > > Why do you find system restore points useless? > > Aren't they convenient, when they work? (as long as you regard it as > a convenience, not a proper backup) The thing is, I've *never* had them work. As such, it's a useless (mis)feature for me. I don't understand in what circumstances System Restore is supposed to "work". My naïve understanding is that it should restore the disk to the condition it was in at the point the restore point was made. Obviously, this isn't what happens. So all I know is that *some* things will go back to the condition they were in when the restore point was taken. This is worse than any other possible case IMO - now rather than 1 thing broken, and number of things are broken. For this reason, I turn off System Restore at the earliest opportunity, and use Ghost (or other imaging tool, but usually Ghost). Turning off System Restore frees up hard drive space and improves performance - both very important when building low-spec (P2 400 or lower) machines for family ;) Tim Delaney

1 0

RE: [Python-checkins] python/nondist/sandbox/decimal libdecimal.tex, NONE, 1.1
by Tony Meyer 04 Jul '04

04 Jul '04

[...] > \moduleauthor{Tim Peters}{guido(a)python.org} [...] Is this correct? (I guess it could be, but it does look odd). =Tony Meyer

1 0

Re: [Python-Dev] VC 7.1 maintenance?
by Thomas Heller 03 Jul '04

03 Jul '04

"Tim Peters" <tim.one(a)comcast.net> writes: > [Thomas Heller] >> Well, I would be much happier to build an installer with inno setup >> instead of Martin's msi code, which I don't understand ;-(. > > So the choice is Martin's MSI code you don't understand, or your Inno > RemObjects Object Pascal code Martin doesn't understand <wink>? Probably I'm not smart enough to understand (or even maintain) Martin's MSI code, but I guess Martin will be smart enough to understand a little Pascal. >> Are there really technical reasons the VC7.1 built Python binaries must >> be distributed via msi technology or not? > > The most frequently requested thing MSI provides is the ability for admins > to use MS Group Policy to push installs out to boxes on a network. This > hasn't been requested often ("most frequently" is a relative measure ...). I was asking because I'm not sure if there will be problems with Windows file system protection with non-MSI installers. Thomas

4 5

Re: [Python-Dev] Re: decorators and 2.4
by Jewett, Jim J 03 Jul '04

03 Jul '04

Jeff Bone: > Yet --- true, but only if one accepts a particular and rather > simple-minded and overly-literal interpretation of the ***GOALS*** of > PEP 318, That simple-minded and overly-literal interpretation may well be correct. PEP 318 does not intend to change the semantics or capabilities of the language in any way whatsoever. The only reason to add 318 is so that a particular idiom will be easier to understand (and perhaps more efficient). The other goals are really damage control. If the idiom becomes easy to use, it will get used more often. Sometimes, that will be good, as it will replace something more byzantine. It is true that we don't want to encourage certain types of coding, but they're already possible, and the consensus was not to ban them now. Discourage in a style guide, maybe, but not ban. The arguments about syntax are because we don't want the new and improved idiom to end up uglifying the rest of the language. Ideally, any change will remove more clutter than it creates, so adding new meaning to certain magic characters ... is risky. If we put restrictions on decorators, people may just keep using the current idiom -- and then we would have added the clutter for no gain at all. -jJ

6 5

Re: [Python-checkins] python/dist/src/Doc/whatsnew whatsnew24.tex, 1.55, 1.56
by A.M. Kuchling 02 Jul '04

02 Jul '04

On Thu, Jul 01, 2004 at 04:52:17AM -0700, rhettinger(a)users.sourceforge.net wrote: > Modified Files: > whatsnew24.tex > Log Message: > Move Decimal from the sandbox into production. Um, I'd really like to write my own text for this document. Please don't go to the effort of writing "What's New" sections. --amk

3 4

useless question in bdist_wininst installers
by Thomas Heller 02 Jul '04

02 Jul '04

I just submitted <http://www.python.org/sf/984290>, which contains this text: Before a bdist_wininst created installer overwrites files it asks the user whether files should be overwritten or not. This question is annoying and doesn't seem very useful - it is too late to cancel the installation (because some files might already have been installed). I suggest to remove this question (MessageBox), and always overwrite files during the installation. Any comments? Thomas

1 0

python-dev Summary for 2004-06-16 through 2004-06-30 [draft]
by Brett Cannon 02 Jul '04

02 Jul '04

For as long as I can remember, when I have sent out a rough draft of a summary, it has been delayed long enough that I had a bunch of emails already for the next summary. Well everyone, I managed to finally have my python-dev folder have an email count less than the number of fingers I have on a hand (and I still have all of my fingers). You can thank a hiccup in my workload for that (and thus me not earning any money today). It almost seems wrong that I don't have enough emails to cause a scrollbar to appear. =) Won't send this out any earlier than the 4th so you have at least until then to send in corrections. ------------------------------------ Summary Announcements ===================== The trouble plaguing mail.python.org mid-month have been cleared up. It had led to some rather delayed emails so if you sent one in and it was ignored for no good reason you might want to consider bringing the topic back up. In the little comment made by the summary count, I questioned whether that count was correct. Turns out it was off by one; this is the true forty-third semi-monthly summary by me (month-long summaries I counted twice). So counting the two week span that I took off when Raymond Hettinger summarized for a week way back in October 2002 (still waiting for the second week, Raymond =) I have been doing this for 22 months straight. And yet after all of that email I still have my eye sight. Amazing. Summaries ========= --------------------------------------------- Decimal type still chugging along --------------------------------------------- Facundo Batista updated `PEP 327`_ with what are close to the last issues for the PEP. There has also been some recent activity in the sandbox on the package. It could still make it into 2.4 ... And it has! As I wrote this Decimal.py graduated kindergarten, left the sandbox, and is now out on the playground with the rest of Lib. Play nice. .. _PEP 327: http://www.python.org/peps/pep-0327.html Contributing threads: - `PEP 327 (Decimal data type) updated and status <http://mail.python.org/pipermail/python-dev/2004-June/045434.html>`__ ------------------------------------------------- CVS docs, now in handy tarball form ------------------------------------------------- Fred Drake has tweaked the script that puts up new versions of the CVS docs to also upload a tarball of the HTML. You can find that and links to the other in-development documentation at http://www.python.org/dev/doc/ . Contributing threads: - Downloadable HTML from the trunk <`http://mail.python.org/pipermail/python-dev/2004-June/045452.html`>__ --------------------------------------------- Proposed additions to heapq API --------------------------------------------- Raymond Hettinger proposed adding two new functions to the heapq API. heappushpop() would take an item, push it on to the heap, and then pop off the smallest value. heapiter() would return a destructive iterator. The actual implementation of heappushpop() got the most discussion. No finally decision has been made, so if either function sounds good to you then do speak up. Contributing threads: - `heapq API <http://mail.python.org/pipermail/python-dev/2004-June/045348.html>`__ --------------------------------------- Consolidation of CJK codecs --------------------------------------- Hye-Shik Chang consolidated the various CJK codecs into various files and managed to save some space in terms of the files themselves. As M-A Lemburg pointed out, though, there was no need to in terms of loading size since most linkers mmap only what is needed to run. Contributing threads: - `Planned updates for cjkcodecs before 2.4a1 <http://mail.python.org/pipermail/python-dev/2004-June/045415.html>`__ ------------------------------------------------ Function decorators in 2.4 ... maybe ------------------------------------------------ The topic of whether function decorators would go into 2.4, and if so with what syntax, continued to be debated from the `last summary`_. Beyond reference implementations, nothing really changed. Overall people agreed they would like to see it in 2.4 using whatever syntax Guido chooses (and he has three in mind, so no more suggestions!), but if he felt the need to wait then functionality would be held off for 2.5 . Contributing threads: - `functions decorators in 2.4? <http://mail.python.org/pipermail/python-dev/2004-June/045440.html>`__ - `decorators and 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045516.html>`__ ------------------------------------------------------------------------- Making ``''.join(list_of_strs)`` an inconsequential idiom ------------------------------------------------------------------------- As most people know, concatenating strings in a 'for' loop is a bad idea; the idiom you are supposed to use is to store the strings you want to concatenate in a list and the pass it to ``''.join(list_of_strs)``. This is because string addition requires allocating memory for the size of the concatenation and then copying from both strings into the new memory. The constant new memory allocation is costly when you have a loop that goes for more than a few iterations. Raymond Hettinger suggested altering the str object to have a pointer that would point to any strings that were meant to be treated as concatenated to the current string. The problem with this is that it grew the str object the size of a pointer and that is costly for a object as common as string. Armin Rigo gave this challenge a shot and ended up with a bunch of code that special-cases the BINARY_ADD opcode. Neither solution as been accepted at this moment. Contributing threads: - `Wild Idea for the Year <http://mail.python.org/pipermail/python-dev/2004-June/045488.html>`__ - `Building strings with += <http://mail.python.org/pipermail/python-dev/2004-June/045504.html>`__ ---------------------------------------------------------------------------------------- Possible exposure of universal newlines outside of the file object ---------------------------------------------------------------------------------------- Scott David Daniels suggested a new itertools functioned that would work like universal newlines but for strings or files already opened without universal newlines turned on. People were receptive to the idea, just not for putting it into itertools. Suggestions ranged from exposing the functionality as a static method of the file type to sticking into 'string'. No conclusion of where to put it was reached. Contributing threads: - `Possible addition to itertools <http://mail.python.org/pipermail/python-dev/2004-June/045456.html>`__ ---------------------------------- NOP does exist I tell you! ---------------------------------- Raymond Hettinger asked if anyone objected to adding a no-op opcode (aptly named NOP). People said nope (see? "NOP", "nope", sound the same? <eddie izzard>Forget it</eddie izzard>). So it's in. Contributing threads: - `NOP <http://mail.python.org/pipermail/python-dev/2004-June/045491.html>`__ --------------------------------------------------------------- Yes, the Windows binary for 2.4 will use VC 7.1 --------------------------------------------------------------- Yes, Python 2.4 will use VC 7.1 . No, we are not going to have a VC 6 binary (you can build it if you want, though). No, distributing the needed DLLs with the installer go against the GPL (even though the codebase is not GPL but more BSD and no one from the FSF has told it including the DLLs is wrong). Maybe, we will use Martin v. Loewis' MSI installer, maybe not (still being debated as this was being written). Contributing threads: - `VC 7.1 maintenance? <http://mail.python.org/pipermail/python-dev/2004-June/045357.html>`__ ------------------------------------- Possible itertools additions ------------------------------------- Raymond Hettinger suggested two itertools additions; count_elements and pairswap. The former counts the number of times an item appears in the passed-in iterable and returns pairs of the count and the item. The latter takes an iterable that returns pairs and returns and iterable that returns those pairs swapped. In the end people didn't see the need for pairswap. People did want count_elements, but not as an iterator but as something that returned a dictionary. It was suggested as both a class method of dict and as a new bucket type that could possibly go into the 'collections' module. No final decisions yet, though. Contributing threads: - `Candidate Itertools <http://mail.python.org/pipermail/python-dev/2004-June/045394.html>`__ -------------------------------- Gettin' PEP 292 into 2.4 -------------------------------- Barry Warsaw brought up the point that `PEP 292`_ was slated to go into 2.4 (it's currently in the sandbox). The two biggest questions was the names of the new functions and where to stick them. The name issue was not quite as bad once Barry explained the reasoning behind the existing names. Where to put the code, though, was not so easily dealt with. The original idea (which Barry and I came up with, so I am biased here) was to turn the string module into a package with the new code going there. Barry also pointed out that the code in 'string' that is deprecated and will eventually go away can be moved into an individual module that can just simply be deleted from the package later and change a single ``import *`` line in __init__.py for the package. Not everyone saw the utopia Barry and I were trying to build. People suggested just not bothering with turning 'string' into a package. Still others suggested a new package altogether; 'stringlib' and 'text' were suggested names. It's still not resolved. .. _PEP 292: http://www.python.org/peps/pep-0292.html Contributing threads: - `PEP 292 for Python 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045406.html>`__ ------------------------------------------------------------------------- Having u.encode() return something other than strings ------------------------------------------------------------------------- Currently unicode.encode() returns only strings. M-A Lemburg wanted to lift this restriction. Guido pointed out that this could possibly cause problems for type inferencing since the return type would vary based on an argument (which made me happy since my masters thesis ties into this stuff). A compromise was reached where the method will only return 8-bit or Unicode strings; basically only subtypes of basestring. Contributing threads: - `Allowing u.encode() to return non-strings <http://mail.python.org/pipermail/python-dev/2004-June/045417.html>`__ -------------------------------------------------- Comparing floats and longs is a pain -------------------------------------------------- Basically this all boiled down to this (quoted from Michael Chermside): "when comparing a long with a float where the exponent is larger than the precision, that the float should be treated as if it were EXACTLY EQUAL TO <coefficient>*2^<exponent>, instead of trying to treat it as some sort of a range." Guido said he would like to see this in 2.4 if someone would write up the code and commit it. Contributing threads: - `Comparing heterogeneous types <http://mail.python.org/pipermail/python-dev/2004-June/045460.html>`__ ---------------------------------------------------------- German and Turkish docstrings from pydoc ---------------------------------------------------------- Martin v. Loewis is currently trying to figure out where to put partial translations of docstrings in the stdlib for pydoc to use as appropriate. Contributing threads: - `Including translated doc strings in 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045490.html>`__ ------------------------------------------------------------------------------------------- What to do when 'raise' is called after the last exception was caught ------------------------------------------------------------------------------------------- What should happen if you call 'raise' when you already caught the last exception that was raised? People debated what the official docs said. Seemed to coalesce to be what ever the last exception was; caught or not. This ties into being what exception was currently stored. Contributing threads: - `Re-raise in absence of an "active" exception <http://mail.python.org/pipermail/python-dev/2004-June/045497.html>`__ --------------------------------------------------------------------- Can you help with cleaning up the Demo directory? --------------------------------------------------------------------- The Demo directory is in need of some TLC. A bunch of modules in there are out of date and could use an update to current Python abilities. If you care to help by submitting patches to update the code that would be great. There is a large swath of code in there varying from extremely simple to involved so if the mood ever strikes you there will be something for everyone. And if you attend the next Python Bug Day you can also work on it then. Contributing threads: - `What can we do about dealing with the Demo directory? <http://mail.python.org/pipermail/python-dev/2004-June/045654.html>`__ -------------------------------------------------------------------- No more expected test failures on Windows for 2.4 -------------------------------------------------------------------- The bsddb tests are now expected to pass on Windows. What this means is that failures are no longer the norm on Windows for the Python regression testing suite. Contributing threads: - `Joy in Berkeley Windowsland <http://mail.python.org/pipermail/python-dev/2004-June/045669.html>`__ ------------------------------------------------------ Getting accessible local dicts per thread ------------------------------------------------------ Jim Fulton wanted to expose the pre-thread local dict . He has an implementation going that he is going to play with and work the kinks out of. After that the code will most likely be committed. Contributing threads: - `Proposal: thread.get_dict <http://mail.python.org/pipermail/python-dev/2004-June/045681.html>`__ -------------------------------- Where to stick SHA-256 -------------------------------- Someone contributed a patch for adding SHA-256 support. A discussion built up over where to put it, if at all. It's still going on at this moment. Most people seem to agree that if it is included, it should either just be another function in the sha module or that sha.sha() should accept an optional argument specifying how many bits to use for the hash. Contributing threads: - `SHA-256 module <http://mail.python.org/pipermail/python-dev/2004-June/045724.html>`__ ------------------------------------------ Making weakrefs subclassable ------------------------------------------ Fred Drake has a patch to add the ability to subclass weakrefs. He wasn't sure if there would be a performance penalty though. But Tim Peters stepped up and said there wouldn't be. So it looks like it should go in shortly. Contributing threads: - `making weakref.ref objects subclassable <http://mail.python.org/pipermail/python-dev/2004-June/045787.html>`__

3 5