Mailman 3 October 2004 - Python-Dev

Fwd: [Python-Dev] Python 2.4b1 on win32 installer bug?
by Alex A. Naanou 19 Oct '04

19 Oct '04

Martin wrote: > Also, upgrading from 2.4a3 (with extensions installed) to 2.4b1 > (with no extensions) would have the same effect - there is simply > no support for restoring older versions of the extensions when > uninstalling (and upgrading from 2.4a3 to 2.4b1 is actually the > same as uninstalling 2.4a3 first). this appears to be exactly the case with me, I run both the 2.3 and 2.4 branches on the same box... and I upgraded py2.4a3 to py2.4b1. the funny thing is that when I installed Py2.4a3 some time back all went well. this time the installer restored the last setup options (except the setup dir... I do not use %systemdrive%\python24\) and removed ALL file associations, including for Py2.3.4, and messed up the overall python registry configuration! (which is quite odd....). -- Alex.

1 1

Re: [Python-Dev] Changing pymalloc behaviour for long running
by Luis P Caamano 19 Oct '04

19 Oct '04

> "Martin v. L?wis" <martin(a)v.loewis.de> wrote: > > Evan Jones wrote: > > Some posts to various lists [1] have stated that this is not a real > > problem because virtual memory takes care of it. This is fair if you > > are talking about a couple megabytes. In my case, I'm talking about > > ~700 MB of wasted RAM, which is a problem. > > This is not true. The RAM is not wasted. As you explain later, the > pages will be swapped out to swap space, making the RAM available > again for other tasks. > > > First, this is wasting space > > which could be used for disk cache, which would improve the performance > > of my system. > > And indeed, this is what the operating system does for you: free the > memory (by swapping it out), then using the memory for disk cache, thus > improving performance of your system. Your statements above assume that swapping is OK but that's not necessarily true. Some of our daemons run on systems with no swap or extremely slow swap. Either way it's bad if the system has to swap out 50-100 MBs of "unused" memory. Now, that's a waste. -- Luis P Caamano Atlanta, GA USA

1 0

Re: python/dist/src/Doc/lib libzlib.tex,1.28,1.29
by Fredrik Lundh 19 Oct '04

19 Oct '04

akuchling(a)users.sourceforge.net wrote: > Index: libzlib.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/lib/libzlib.tex,v > retrieving revision 1.28 > retrieving revision 1.29 > diff -u -d -r1.28 -r1.29 > --- libzlib.tex 21 Jun 2003 14:15:25 -0000 1.28 > +++ libzlib.tex 19 Oct 2004 18:52:49 -0000 1.29 > @@ -9,8 +9,8 @@ > For applications that require data compression, the functions in this > module allow compression and decompression, using the zlib library. > The zlib library has its own home page at > -\url{http://www.gzip.org/zlib/}. Version 1.1.3 is the > -most recent version as of September 2000; use a later version if one > +\url{http://www.gzip.org/zlib/}. Version 1.2.1 is the > +most recent version as of October 2004; use a later version if one > is available. There are known incompatibilities between the Python > module and earlier versions of the zlib library. that's somewhat misleading, isn't it? version 1.2.1 is of course the most recent version right now, but zlib works just fine with 1.1.3 or later. I suggest rephrasing the "known incompatibilities" part to recommend 1.1.4 or later (there's a known security problem with 1.1.3; see http://www.gzip.org/zlib/advisory-2002-03-11.txt for details). </F>

1 0

import w/options
by Neal D. Becker 19 Oct '04

19 Oct '04

I have an application where it would be useful to set RTLD_GLOBAL on dlopen when import is used. Currently, python doesn't provide this option. Why not allow an optional argument to import that would allow this?

4 4

alternate pty module available
by J Raynor 18 Oct '04

18 Oct '04

See the following threads for some background: http://mail.python.org/pipermail/python-dev/2004-September/049085.html http://mail.python.org/pipermail/python-dev/2004-September/049092.html I've created a python module called altpty that uses code from Openssh to implement openpty() and forkpty() functions. They should work across more platforms than the functions from the standard pty module. The module can be downloaded from: http://home.mn.rr.com/raynorj/altpty.tar.gz Installation instructions are in the INSTALL file. I believe you'll need python 2.2 or better to build the module. There's still some cleanup work that could be done, but the module works, and I wanted to make it available and see if there was any real interest in it before I put too much effort into getting everything just so. Send comments or bug reports to raynorj AT mn.rr.com.

2 1

[Python-Dev] RE: [Python-checkins] python/dist/src/Lib _strptime.py, 1.35, 1.36
by Tony Meyer 18 Oct '04

18 Oct '04

> Index: _strptime.py [...] > + # For some reason when Dec 31 falls on a Monday the > week of the year is > + # off by a week; verified on both OS X and Solaris. > + elif weekday == 0 and week_of_year_start == 6 and > week_of_year >= 52: > + week_of_year += 1 Is this right? At the moment, if I ask for Monday in the 52nd week of 2008, I get the 5th of January 2009: >>> time.strptime("2008 52 1", "%Y %U %w") (2009, 1, 5, 0, 0, 0, 0, 371, -1) For reference, Monday in the previous week is the 22nd of December: >>> time.strptime("2008 51 1", "%Y %U %w") (2008, 12, 22, 0, 0, 0, 0, 357, -1) Wouldn't December 29 2008 be the right answer? This is the result without that if: >>> time.strptime("2008 52 1", "%Y %U %w") (2008, 12, 29, 0, 0, 0, 0, 364, -1) This is with WinXP SP1. =Tony Meyer

3 3

Adding support for %U and %W for strptime in b2
by Brett C. 18 Oct '04

18 Oct '04

http://www.python.org/sf/1045381 is a bug report about how strptime does nothing with %U and %W directives (week of the year with differences in whether Sunday or Monday starts the week). I just finished getting the algorithm to calculate the date given the year, either of %U or %W and the day of the week. Now the question is whether this is a bug fix or a feature implementation. If it is a bug fix I can check it right in. The only reason it wasn't in since the beginning is I didn't think of the day of the week being all you needed to figure out the date with %W or %U. If it is considered a feature, though, I will just add a note that %U and %W consume values but do nothing with them. So, what do you all think? -Brett

3 2

RE: [Python-Dev] ConfigParser patches
by Daniel 'Dang' Griffith 17 Oct '04

17 Oct '04

At 11:43 PM 10/2/2004, python-dev-request(a)python.org wrote: > Date: Sat, 2 Oct 2004 21:14:07 -0400 > From: "Raymond Hettinger" <python(a)rcn.com> > Subject: RE: [Python-Dev] ConfigParser patches > To: <guido(a)python.org> > Cc: python-dev(a)python.org > Message-ID: <000801c4a8e6$6217fc20$e841fea9@oemcomputer> > Content-Type: text/plain; charset="us-ascii" > > > I was in fact thinking of the -m proposal when I wrote that... > > The timing does suck. > > > It's so easy to define an alias or use a one-line shell script for > > invoking Python with a full pathname that I'm really not sure I like > > the -m idea, > > My understanding was that it wasn't about a full pathname to python, it > was about searching sys.path for the darned script so us poor Windows > guys don't have to change directories a million times a day (no aliases > or shebangs for us either). > > I have a big pile of batch files just to invoke timeit, texchecker, > profile, etc. It bites the big one. Am I missing something? I run python scripts all the time from the command line in Windows. Modify your PATHEXT environment variable: PATHEXT=.PY;.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH Then put your script directory into your PATH: PATH=C:\Python23\lib;%PATH% The first time you run timeit (or whatever.py), Windows will prompt you to associate the .py extension with a program. Pick your favorite python.exe. You can also do this manually before running your script. From then on, you're set: C:\>timeit -s "a=range(20)" "a.append(1)" "a.pop()" 1000000 loops, best of 3: 1.13 usec per loop --dang p.s. You can put .pyc in your path too, but then you'll get the compiled version even if the uncompiled version is newer. But you can always compile them.

2 1

RE: ConfigParser shootout, preliminary entry
by Michael Chermside 17 Oct '04

17 Oct '04

My apologies, my previous email was intended to go to python-list, not python-dev. I didn't intend to bother this list with it until it was at a point where I thought it was a contender for inclusion. Sometimes I really wish there was an "Unsend" option for email. -- Michael Chermside

1 0

RELEASED Python 2.4, beta 1
by Anthony Baxter 17 Oct '04

17 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I'm happy to announce the first beta of Python 2.4. Python 2.4b1 is an beta release. We'd greatly appreciate it if you could download it, kick the tires and let us know of any problems you find, but it is probably not suitable for production usage. ~ http://www.python.org/2.4 Notable changes in beta1 include a new subprocess module to provide a more convenient interface to spawning processes and a new command line argument -m modulename to run a module from the library. See either the highlights, the What's New in Python 2.4, or the detailed NEWS file -- all available from the Python 2.4 webpage. This is the first beta release of Python 2.4. Python 2.4 is now in the beta part of the release cycle - there should be few or no new features, merely bug fixes. There will be at least one more beta in a couple of weeks, followed by a release candidate and then the final release. Please log any problems you have with this release in the SourceForge bug tracker (noting that you're using 2.4b1): ~ http://sourceforge.net/bugs/?group_id=5470 Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBcoEMDt3F8mpFyBYRAhJhAKCCclb5ytuljQIGvIz9dIV2LmL0KQCgl5DX 357fPses//NSjyK+7B10YPg= =lzWC -----END PGP SIGNATURE-----

1 0