Mailman 3 September 2005 - Python-Dev

bool(iter([])) changed between 2.3 and 2.4
by Jim Jewett Sept. 22, 2005

Sept. 22, 2005

Greg Ewing wrote: > But if the docs don't mention anything about true or > false values for some particular type, one tends to > assume that all values are true, as is the default > for user-defined classes. The tutorials and such stress that python doesn't typically care about a specific "True" or "False"; the normal distinction is between "empty" and "not empty". 0, None, (), [], {} all come out as false. "Is there anything left?" is a pretty analogy for iterators, … [View More]

3 2

Re: [Python-Dev] os.path.diff(path1, path2) (and a first post)
by richard barran Sept. 22, 2005

Sept. 22, 2005

On Sat, 17 Sep 2005, John J Lee wrote: > > On Fri, 16 Sep 2005, Greg Ewing wrote: > > > Trent Mick wrote: > > > > > If this *does* get added (I'm +0) then let's call it "relpath" or > > > "relpathto" as in the various implementations out there: > > > > +1 on that, too. Preferably just "relpath". > [...] > > +1 on adding this function, and on "relpath" as the name. I wanted this > function just a few weeks ago. Hello … [View More]

3 2

GIL, Python 3, and MP vs. UP
by Sokolov Yura Sept. 22, 2005

Sept. 22, 2005

Ok. While windows already prefers threads, while linux-2.6 improves thread support and speed, while process startup expensive on time and memory, while we ought to dublicate our data and/or use obscure shared memory, while it is much simpler to make threaded program with care just about locks than multiprocessing with inventing interchange protocol (which abuses both CPU - sender and reciever), MULTIPROCESSING RULES!!! And on Opterons: you will win with multiprocessing ONLY if OS will … [View More]

6 6

Re: [Python-Dev] vendor-packages directory
by Phillip J. Eby Sept. 22, 2005

Sept. 22, 2005

At 01:18 PM 9/22/2005 -0700, Rich Burridge wrote: >Phillip J. Eby wrote: >>Right - I'm proposing you add a vendor-packages.pth file to >>site-pacakges, that points to a "totally separate base directory" where >>those files are installed, not that you install the packages themselves >>under site-packages. To make sure we're disagreeing about the same thing >><0.5 wink>, here's what I'm suggesting: >>1. Install your packages in /usr/lib/python2.4/… [View More]vendor-packages (so far, >>so good, we agree on this part) >>2. Create a 'vendor-packages.pth' file in >>/usr/lib/python2.4/site-packages, containing the line: >> /usr/lib/python2.4/vendor-packages >>This will ensure that your vendor-packages "just work", unless locally >>overridden in site-packages. >>So, you install one .pth file, once, as part of your installation of >>Python itself, and it works *now*, without waiting for a new Python >>release or complicating any other Python code or requiring agreement >>between vendors about how to do this. This is one of the things that >>.pth files are for, and I believe it should be the recommended way for >>operating systems to establish OS-specific modifications to the default >>Python module search path. Otherwise, everybody will be patching site.py >>for their specific OS, and there are already too many OS-specific things >>in that code, and for backward-compatibility reasons we can't get rid of >>them in Python 2.x. I don't think we want to add new ones. > >Bob Ippolito wrote: > > vendor-packages.pth should look like this (evil, but practical): > > > > import site; site.addsitedir('/usr/lib/python2.4/vendor-packages') > > > > Otherwise packages like Numeric, PIL, PyObjC, etc. that take advantage > > of pth files will not work when installed to that location. > >Thanks! I'll work with the architectural committee in question to see if they >are happy with this approach to solving the problem. Glad we could help. Unfortunately, there isn't any sort of document at the moment for "Python Distributors" to help explain how these kinds of problems should be solved. It would probably be a good idea for us to have one. Perhaps a volunteer or two could be found on the distutils-SIG who could help put one together, since a certain number of distributions' Python gurus tend to hang out there. (By the way, assuming this solves your problem fully, don't forget to withdraw your patch on SF, optionally citing the python.org archive URL for this email.) [View Less]

1 0

vendor-packages directory
by Rich Burridge Sept. 22, 2005

Sept. 22, 2005

Hi, Recently I asked about the inclusion of a "vendor-packages" directory for Python on the Python mailing list. See the thread started at: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request, and the replies I received. I then approached Guido for his take on this suggestion. He recommended I submit the patch to the Python patch manager at SourceForge, and inform the folks on python-dev mailing list. So I have. You can … [View More]

3 3

Re: [Python-Dev] vendor-packages directory
by Phillip J. Eby Sept. 22, 2005

Sept. 22, 2005

At 12:04 PM 9/22/2005 -0700, Rich Burridge wrote: >Phillip J. Eby wrote: >>>Recently I asked about the inclusion of a "vendor-packages" >>>directory for Python on the Python mailing list. >>> >>>See the thread started at: >>> >>>http://mail.python.org/pipermail/python-list/2005-September/300029.html >>> >>>for the full reasoning behind this request, and the replies >>>I received. >> >>I'm with Terry … [View More]on this, it needs a better rationale. Why can't you just >>add a .pth file to the site-packages directory? It seems that would >>address the issue nicely. >>(See http://docs.python.org/lib/module-site.html for documentation of the >>.pth mechanism, which would let you implement a separate vendor-packages >>directory without modifying Python, and would still allow local overrides >>of your vendor packages.) > >I understand how .pth files work. > >The rationale for requesting the "vendor-packages" approach, is that >Python files, >as supplied by the vendor (Sun, Apple, RedHat ...) with their operating >system >software, should go in a totally separate base directory, to differentiate >them >from Python files installed specifically at one site. Right - I'm proposing you add a vendor-packages.pth file to site-pacakges, that points to a "totally separate base directory" where those files are installed, not that you install the packages themselves under site-packages. To make sure we're disagreeing about the same thing <0.5 wink>, here's what I'm suggesting: 1. Install your packages in /usr/lib/python2.4/vendor-packages (so far, so good, we agree on this part) 2. Create a 'vendor-packages.pth' file in /usr/lib/python2.4/site-packages, containing the line: /usr/lib/python2.4/vendor-packages This will ensure that your vendor-packages "just work", unless locally overridden in site-packages. So, you install one .pth file, once, as part of your installation of Python itself, and it works *now*, without waiting for a new Python release or complicating any other Python code or requiring agreement between vendors about how to do this. This is one of the things that .pth files are for, and I believe it should be the recommended way for operating systems to establish OS-specific modifications to the default Python module search path. Otherwise, everybody will be patching site.py for their specific OS, and there are already too many OS-specific things in that code, and for backward-compatibility reasons we can't get rid of them in Python 2.x. I don't think we want to add new ones. [View Less]

2 1

Re: [Python-Dev] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
by Wilfredo Sánchez Vega Sept. 22, 2005

Sept. 22, 2005

IIRC, it doesn't exist on such a system; that's a Mac OS command, not a Darwin command. (The man page correctly has "Mac OS X" in the footnote, not "Darwin" or "BSD", though I don't know that you can rely on that 100%.) -wsv On Sep 22, 2005, at 10:20 AM, Guido van Rossum wrote: > On 9/22/05, Wilfredo Sánchez Vega <wsanchez(a)apple.com> wrote: > >> "rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on >> anything we ship today. >> >… [View More]

1 0

Re: [Python-Dev] unintentional and unsafe use of realpath()
by Peter Jones Sept. 22, 2005

Sept. 22, 2005

[re-adding Python-Dev] On Wed, 2005-09-14 at 02:00 +0200, Henrik Levkowetz wrote: > Hi Peter, > > on 2005-09-10 21:29 Peter Jones said the following: > > Hi, > > > > In Python 2.4.1, Python/sysmodule.c includes a function PySys_SetArgv(). > > One of the things it does is attempt to resolve symbolic links into > > absolute paths. Currently, it uses readlink() if configure found that > > your system supports it, and then it tries to do the same … [View More]thing again > > using realpath() if you system supports that. > > > > This seems wrong; there's really no reason to do both. So here's a > > patch to move the realpath() usage into a #else following the > > HAVE_READLINK test: > > > > If a path component above the basename is a link, it will not be > resolved by only doing readlink() on the basename, while realpath() will > resolve it. So it seems to me that your proposed patch will accomplish > less than the current code for systems which have realpath(). What the current code is doing is a buffer overrun. Nevertheless, you're right that it would behave differently than the current code if that code worked as intended. Here's a different patch; it uses canonicalize_file_name instead, and if you don't have that it just uses the same codepath that's already in the tree. canonicalize_file_name is identical to realpath() when using the glibc extension of allocating a buffer when you pass in a NULL target, as in: fullpath = realpath(path, NULL); I chose to use canonicalize_file_name simply because the autoconf test for it is easier than testing to see if the extension works. Here's the new patch: --- Python-2.4.1/pyconfig.h.in.canonicalize 2005-09-14 11:47:04.000000000 -0400 +++ Python-2.4.1/pyconfig.h.in 2005-09-14 11:47:02.000000000 -0400 @@ -58,6 +58,9 @@ /* Define if pthread_sigmask() does not work on your system. */ #undef HAVE_BROKEN_PTHREAD_SIGMASK +/* Define to 1 if you have the `canonicalize_file_name' function. */ +#undef HAVE_CANONICALIZE_FILE_NAME + /* Define to 1 if you have the `chown' function. */ #undef HAVE_CHOWN --- Python-2.4.1/Python/sysmodule.c.canonicalize 2005-09-14 11:53:30.000000000 -0400 +++ Python-2.4.1/Python/sysmodule.c 2005-09-14 11:52:04.000000000 -0400 @@ -1184,6 +1184,9 @@ char *p = NULL; int n = 0; PyObject *a; +#ifdef HAVE_CANONICALIZE_FILE_NAME + argv0 = canonicalize_file_name(argv0); +#else /* ! HAVE_CANONICALIZE_FILE_NAME */ #ifdef HAVE_READLINK char link[MAXPATHLEN+1]; char argv0copy[2*MAXPATHLEN+1]; @@ -1256,6 +1259,7 @@ #endif /* Unix */ } #endif /* All others */ +#endif /* ! HAVE_CANONICALIZE_FILE_NAME */ a = PyString_FromStringAndSize(argv0, n); if (a == NULL) Py_FatalError("no mem for sys.path insertion"); --- Python-2.4.1/configure.in.canonicalize 2005-09-14 11:46:00.000000000 -0400 +++ Python-2.4.1/configure.in 2005-09-14 11:47:22.000000000 -0400 @@ -2096,8 +2096,8 @@ AC_MSG_RESULT(MACHDEP_OBJS) # checks for library functions -AC_CHECK_FUNCS(alarm bind_textdomain_codeset chown clock confstr ctermid \ - execv fork fpathconf ftime ftruncate \ +AC_CHECK_FUNCS(alarm bind_textdomain_codeset canonicalize_file_name chown \ + clock confstr ctermid execv fork fpathconf ftime ftruncate \ gai_strerror getgroups getlogin getloadavg getpeername getpgid getpid \ getpriority getpwent getsid getwd \ kill killpg lchown lstat mkfifo mknod mktime \ -- Peter [View Less]

2 2

RELEASED Python 2.4.2, release candidate 1
by Anthony Baxter Sept. 22, 2005

Sept. 22, 2005

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.2 (release candidate 1). Python 2.4.2 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 60 bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.4.2 will follow in about a week's time. For more information on Python 2.4.2, including download … [View More]

1 0

possible memory leak on windows (valgrind report)
by Neal Norwitz Sept. 22, 2005

Sept. 22, 2005

I ran 2.4.x through valgrind and found two small problems on Linux that have been fixed. There may be some other issues which could benefit from more eyes (small, probably one time memory leaks). The entire run is here: http://python.org/valgrind-2.4.2.out (I need to write a lot more suppression rules for gentoo.) I think I see a memory leak in win32_startfile. Since I don't run windows I can't test it. filepath should be allocated with the et flag to PyArgs_ParseTuple(), but it wasn't … [View More]

4 7