Python-Dev October 2004

python-dev@python.org

105 participants
98 discussions

Re: [Python-Dev] Changing pymalloc behaviour for long running

by Luis P Caamano

> "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

16 years, 4 months

Re: python/dist/src/Doc/lib libzlib.tex,1.28,1.29

by Fredrik Lundh

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>

16 years, 4 months

import w/options

by Neal D. Becker

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?

16 years, 4 months

alternate pty module available

by J Raynor

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.

16 years, 4 months

[Python-Dev] RE: [Python-checkins] python/dist/src/Lib _strptime.py, 1.35, 1.36

by Tony Meyer

> 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

16 years, 4 months

Adding support for %U and %W for strptime in b2

by Brett C.

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

16 years, 4 months

RE: [Python-Dev] ConfigParser patches

by Daniel 'Dang' Griffith

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.

16 years, 4 months

RE: ConfigParser shootout, preliminary entry

by Michael Chermside

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

16 years, 4 months

RELEASED Python 2.4, beta 1

by Anthony Baxter

-----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-----

16 years, 4 months

Reducing core dependencies for Python on OS X / distutils nit

by Bob Ippolito

Remove CoreServices / CoreFoundation dependencies in core http://python.org/sf/1035255 It came to my attention a couple weeks ago that Python unnecessarily links to a few frameworks on OS X, so I generated a patch that removed these dependencies. I would hope that this is uncontroversial. Presumably Jack has been really busy lately so I understand that this patch didn't make it into b1, but I would like to get it rolled into CVS by *somebody* after CVS is reopened so the final of Python 2.4 doesn't link to a bunch of frameworks for no reason, which potentially (not benchmarked) increases memory usage and startup time because the resultant Python.framework and python interpreter no longer have any explicit dependencies at all (just libSystem, which is linked in by default). -- distutils.util.get_platform() should include sys.version[:3] http://python.org/sf/1035703 On a side note, when I was playing with Python 2.4, I noticed that distutils doesn't create build directories that have the major Python version encoded in them, only the operating system information. This doesn't really make much sense, because extensions and bytecode aren't typically compatible between major versions! Nobody commented on this, but I'm willing to write a patch to create build directories with sys.version[:3] in them if it will be accepted... -bob

16 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 2004