Mailman 3 March 2005 - Python-Dev

Memory Allocator Part 2: Did I get it right?
by Evan Jones 11 Mar '05

11 Mar '05

After I finally understood what thread-safety guarantees the Python memory allocator needs to provide, I went and did some hard thinking about the code this afternoon. I believe that my modifications provide the same guarantees that the original version did. I do need to declare the arenas array to be volatile, and leak the array when resizing it. Please correct me if I am wrong, but the situation that needs to be supported is this: While one thread holds the GIL, any other thread can call PyObject_Free with a pointer that was returned by the system malloc. The following situation is *not* supported: While one thread holds the GIL, another thread calls PyObject_Free with a pointer that was returned by PyObject_Malloc. I'm hoping that I got things a little better this time around. I've submitted my updated patch to the patch tracker. For reference, I've included links to SourceForge and the previous thread. Thank you, Evan Jones Previous thread: http://mail.python.org/pipermail/python-dev/2005-January/051255.html Patch location: http://sourceforge.net/tracker/index.php? func=detail&aid=1123430&group_id=5470&atid=305470

4 8

LinkedHashSet/LinkedHashMap equivalents
by Delaney, Timothy C (Timothy) 11 Mar '05

11 Mar '05

The perennial "how do I remove duplicates from a list" topic came up on c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and LinkedHashMap. I'd thought about proposing these before, but couldn't think of where to put them. It was pointed out that the obvious place would be the collections module. For those who don't know, LinkedHashSet and LinkedHashMap are simply hashed sets and maps that iterate in the order that the keys were added to the set/map. I almost invariably use them for the above scenario - removing duplicates without changing order. Does anyone else think it would be worthwhile adding these to collections, or should I just make a cookbook entry? Cheers. Tim Delaney

14 21

os.access and Unicode
by "Martin v. Löwis" 11 Mar '05

11 Mar '05

Apparently, os.access was forgotten when the file system encoding was introduced in Python 2.2, and then it was again forgotten in PEP 277. I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder whether this is a backport candidate. People who try to invoke os.access with a non-ASCII filename on non-NT+ systems will get a UnicodeError; with the patch, the operation will succeed (assuming the characters are all supported in the file system encoding). Should this be backported? Regards, Martin

4 8

RE: [Python-Dev] RELEASED Python 2.4.1, release candidate 1
by Tony Meyer 10 Mar '05

10 Mar '05

[Martin v. Löwis] >> I'd like to encourage feedback on whether the Windows >> installer works for people. It replaces the VBScript part in the >> MSI package with native code, which ought to drop the dependency on >> VBScript, but might introduce new incompatibilities. [Tim Peters] > Worked fine here. Did an all-default "all users" install, > WinXP Pro SP2, from local disk, and under an account with > Admin rights. I uninstalled 2.4 first. I suppose that's the > least stressful set of choices I could possibly have made, > but at least it confirms a happy baseline. Also works fine for me with: * WinXP Pro SP2, from local disk, with admin rights, all defaults, over the top of 2.4.0 * Win2k SP4, from network disk, without admin rights, all defaults, with no previous 2.4 * Win2k SP4 (different machine), from local disk, with admin rights, defaults apart from skipped test suite, over the top of 2.4.0 =Tony.Meyer

1 0

branch release24-maint is unfrozen, 2.4.1rc2?
by Anthony Baxter 10 Mar '05

10 Mar '05

Ok, the branch is unfrozen. At the current point in time, I think we're going to need an rc2. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

FWD: SD MAgazine.com - Jolt Awards Winners
by Aahz 10 Mar '05

10 Mar '05

Guido may not be able to go. Anyone else already going? ----- Forwarded message from RLum(a)cmp.com ----- > Subject: Request - SD MAgazine.com - Jolt Awards Winners > To: webmaster(a)python.org > From: RLum(a)cmp.com > Date: Thu, 10 Mar 2005 16:02:35 -0800 > > HI Python.org, > > You may or may not be aware that Python is a finalist in the 15th > Annual Jolt Awards in the Languages and Development Category.The > awards ceremony will take place at SD West, in the Santa Clara > Convention Center, Auditorium, on March 16th from 6:30-7:30 p.m., when > the winners will be announced. Is there anyway that a representative > of Python.org be present to accept the award if they should win? I > will have badges for these individuals at the registration desk to > attend the awards ceremony. > > I understand the Guido van Rossum will be attending SD West. Is there > anyway that he can be present? > > All finalists and conference alumni are invited to a poolside party > with food, drinks and entertainment after the ceremony at the > Westin, which is adjacent to the Conference Center. Hope to see you > there. Dress should be business casual. > > Looking forward to hearing from you. > > Rosalyn > (415) 947-6182 > > > ===================================================== > Rosalyn Lum > Technical Editor > Software Development Magazine > CMP Media > 600 Harrison St., 6th Floor > San Francisco, CA 94107 > www.sdmagazine.com ----- End forwarded message ----- -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR

2 1

SWT PyCon Sprint?
by Nicholas Bastin 10 Mar '05

10 Mar '05

I realize that this is exceedingly late in the game, but is anybody interested in doing a Write-Python-Bindings-for-SWT sprint? It's been brought up before in various places, and PyCon seems the likely place to get enough concentrated knowledge to actually get it kicked off and somewhat working... -- Nick

2 3

RE: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
by Delaney, Timothy C (Timothy) 10 Mar '05

10 Mar '05

Jeff Bauer wrote: > I'm not specifically lobbying for its inclusion in > stdlib, but I often find an ordered dict useful when I > want both ordered and random access, e.g. situations: > > - database table fields/attributes > - drop down field selectors Yep - these are also cases that are familiar to me - it's the type of thing you don't think about until you actually need it. > In both cases, I could get by with other techniques, but I > would use stdlib ordered dicts if they were available. > I also prefer the term "ordered dict" to LinkedHashXXX. You may notice the subject is LinkedHashXXX *equivalents* ;) There is no way I would ever propose adding them with those names. OTOH, "ordered set" and "ordered dict" implies different things to different people - usually "sorted" rather than "the order things were put in". Perhaps "temporally-ordered" ;) BTW, just to clarify the semantics: Set: Items are iterated over in the order that they are added. Adding an item that compares equal to one that is already in the set does not replace the item already in the set, and does not change the iteration order. Removing an item, then re-adding it moves the item to the end of the iteration order. Dict: Keys are iterated over in the order that they are added. Setting a value using a key that compares equal to one already in the dict replaces the value, but not the key, and does not change the iteration order. Removing a key (and value) then re-adding it moves the key to the end of the iteration order. Tim Delaney

6 5

itemgetter/attrgetter extension
by Raymond Hettinger 10 Mar '05

10 Mar '05

Any objections to extending itemgetter() and attrgetter() to be able to extract multiple fields at a time? # SELECT name, rank, serialnum FROM soldierdata map(attrgetter('name', 'rank', 'serialnum'), soldierdata) # SELECT * FROM soldierdata ORDER BY unit, rank, proficiency sorted(soldierdata, key=attrgetter('unit', 'rank', 'proficiency')) Raymond Hettinger

3 2

Re: Python 2.4, distutils, and pure python packages
by Thomas Heller 10 Mar '05

10 Mar '05

The following message is a courtesy copy of an article that has been posted to comp.lang.python as well. [CC to python-dev] "Fuzzyman" <fuzzyman(a)gmail.com> writes: > Python 2.4 is built with Microsoft Visiual C++ 7. This means that it > uses msvcr7.dll, which *isn't* a standard part of the windows operating > system. Nitpicking - it's MSVC 7.1, aka MS Visual Studio .NET 2003, and it's msvcr71.dll. > This means that if you build a windows installer using > distutils - it *requires* msvcr7.dll in order to run. This is true even > if your package is a pure python package. This means that when someone > tries to use a windows installer created with Python 2.4, on a machine > with only python 2.3 - it will fail. Bummer. > It's likely that nothing can be done about this (although for a pure > python package there's no reason not to use the 'source distribution' > and the setup.py). It does mean that I have to build my windows > installer on a machine with python 2.3. There's a workaround, although ugly. bdist_wininst has a --target-version flag which allows to build an installer for another Python version. It works both for pure Python packages, and for (how are they called? non-pure?) packages containing compiled extensions. The 2.4 distutils package has all that is needed to create a installer running with python 2.3 or maybe even 2.2 (which uses msvcrt.dll instead of msvcr71.dll). The result, of course, is that the installer can only install for the version that you specified at build time. Because distutils cannot cross-compile extensions for other versions, you must have build extensions (if there are any to include) with the other Python version before - distutils will simply pick up the extensions it finds in build subdirectories for the other version. Anyway, whether you have extensions or not, you must also specify the --skip-build command line flag, distutils will complain if you don't. So, for a pure distribution you would typically run these commands to build separate installers for 2.3 and 2.4: \python24\python setup.py --skip-build --target-version 2.3 bdist_wininst \python24\python setup.py --skip-build --target-version 2.4 bdist_wininst and for non-pure packages you must compile with each version before building the installer (if you want for some reason to use python 2.4 to build the installer for 2.3): \python24\python setup.py build_ext \python23\python setup.py build_ext \python24\python setup.py --skip-build --target-version 2.3 bdist_wininst \python24\python setup.py --skip-build --target-version 2.4 bdist_wininst OTOH, it's no problem to install both python 2.3 and python 2.4 in separate directories on the same machine and always make native builds. -- To make this story even more complete, there have been also other bugs caused by the different runtime dlls used in 2.3 and 2.4, most only showing when you use the --install-script option. The installer was using msvcrt.dll and msvcr71.dll at the same time, which led to crashes when the install script was started - the PythonCard installer suffered from that, at least. The bug only occurred with pure python distributions, because then the dll problem occurred. The bug is solved in Python 2.3.5, and also in the 2.4.1 release which will be out soon, with one exception: if the install-script prints something the output will be lost instead of displayed on the last screen. At least that's better than crashing the process. Thomas

1 0