> "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
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>
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?
See the following threads for some background:
http://mail.python.org/pipermail/python-dev/2004-September/049085.htmlhttp://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.
> 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
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
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.
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
-----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-----
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