Hi -- there was some talk on this list earlier about nosy
lists, managing patches, and such things, so i just wanted
to mention, for anybody interested, that i threw together
Roundup very quickly for you to try out.
http://www.lfw.org/python/
There's a tar file there -- it's very messy code, and i
apologize (it was hastily hacked out of the running
prototype implementation), but it should be workable
enough to play with. There's a test installation to play
with at
http://www.lfw.org/ping/roundup/roundup.cgi
Dummy user:password pairs are test:test, spam:spam, eggs:eggs.
A fancier design, still in the last stages of coming
together (which will be my submission to the Software
Carpentry contest) is up at
http://crit.org/http://www.lfw.org/ping/sctrack.html
and i welcome your thoughts and comments on that if you
have the spare time (ha!) and generous inclination to
contribute them.
Thank you and apologies for the interruption.
-- ?!ng
"To be human is to continually change. Your desire to remain as you are
is what ultimately limits you."
-- The Puppet Master, Ghost in the Shell
I had to make the following one-line change to socketmodule.c so that it
would link properly with openssl-0.9.4. In studying the openssl include
files, I found:
#define SSLeay_add_ssl_algorithms() SSL_library_init()
SSL_library_init() seems to be the "correct" call nowadays. I don't know
why this isn't being picked up. I also don't know how well the module
works, other than it imports, but I sure would like to try it with
Zope/ZServer/Medusa...
--
andy dustman | programmer/analyst | comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d
"Therefore, sweet knights, if you may doubt your strength or courage,
come no further, for death awaits you all, with nasty, big, pointy teeth!"
Index: socketmodule.c
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.98
diff -c -r1.98 socketmodule.c
*** socketmodule.c 2000/03/24 20:56:56 1.98
--- socketmodule.c 2000/03/30 00:49:09
***************
*** 2384,2390 ****
return;
#ifdef USE_SSL
SSL_load_error_strings();
! SSLeay_add_ssl_algorithms();
SSLErrorObject = PyErr_NewException("socket.sslerror", NULL, NULL);
if (SSLErrorObject == NULL)
return;
--- 2384,2390 ----
return;
#ifdef USE_SSL
SSL_load_error_strings();
! SSL_library_init();
SSLErrorObject = PyErr_NewException("socket.sslerror", NULL, NULL);
if (SSLErrorObject == NULL)
return;
I don't know how much memory other people have in their machiens, but
in this machine (128Mb), I get the following trying to compile a CVS
checkout of Python:
gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./unicodedatabase.c
./unicodedatabase.c:53482: virtual memory exhausted
I hope that this is a temporary thing, or we ship the database some
other manner, but I would argue that you should be able to compile
Python on a machine with 32Mb of RAM at MOST.... for an idea of how
much VM this machine has, i have 256Mb of SWAP on top of it.
Chris
--
| Christopher Petrilli
| petrilli(a)amber.org
Dear Python-developers,
Recently I played with metaclasses from within python,
also with Jim Fulton's ExtensionClass.
I even tried to write my own metaclass in a C-extension, using the
famous Don Beaudry hook.
It seems that ExtensionClass does not completely what I want.
Metaclasses implemented in python are somewhat slow,
also writing them is a lot of work.
Writing a metaclass in C is even more work...
Well, what do I want?
Often, I use the following pattern:
class X:
def __init__ (self):
self.delegate = anObjectImplementedInC(...)
def __getattr__ (self, key):
return self.delegate.dosomething(key)
def __setattr__ (self, key, value):
self.delegate.doanotherthing(key, value)
def __delattr__ (self, key):
self.delegate.doevenmore(key)
This is too slow (for me).
So what I would like do to is:
class X:
def __init__ (self):
self.__dict__ = aMappingObject(...)
and now aMappingObject will automatically receive
all the setattr, getattr, and delattr calls.
The *only* thing which is required for this is to remove
the restriction that the __dict__ attribute must be a dictionary.
This is only a small change to classobject.c (which unfortunately I
have only implemented for 1.5.2, not for the CVS version).
The performance impact for this change is unnoticable in pystone.
What do you think?
Should I prepare a patch?
Any chance that this can be included in a future python version?
Thomas Heller
Here's a second version of the straw man proposal for the reorganization
of modules in packages. Note that I'm treating it as a strictly 1.7
proposal, so I don't care a "lot" about backwards compatiblity.
I'm down to 4 unhandled modules, which means that if no one objects (and
I'm sure someone will <wink>), this can be a plan of action. So get your
objections ready guys!
net
httplib
ftplib
urllib
cgi
gopherlib
imaplib
poplib
nntplib
smptlib
urlparse
telnetlib
server
BaseHTTPServer
CGIHTTPServer
SimpleHTTPServer
SocketServer
asynchat
asyncore
text
sgmllib
htmllib
htmlentitydefs
xml
whatever the xml-sig puts here
mail
rfc822
mime
MimeWriter
mimetools
mimify
mailcap
mimetypes
base64
quopri
mailbox
mhlib
binhex
parse
string
re
regex
reconvert
regex_syntax
regsub
shlex
ConfigParser
linecache
multifile
netrc
bin
gzip
zlib
aifc
chunk
image
imghdr
colorsys
imageop
imgfile
rgbimg
yuvconvert
sound
sndhdr
toaiff
audiodev
sunau
sunaudio
wave
audioop
sunaudiodev
db
anydbm
whichdb
bsddb
dbm
dbhash
dumbdbm
gdbm
math
bisect
fpformat
random
whrandom
cmath
math
crypt
fpectl
fpetest
array
md5
mpz
rotor
sha
time
calendar
time
tzparse
sched
timing
interpreter
new
py_compile
code
codeop
compileall
keyword
token
tokenize
parser
dis
bdb
pdb
profile
pyclbr
tabnanny
symbol
pstats
traceback
rlcompleter
security
Bastion
rexec
ihooks
file
dircache
path -- a virtual module which would do a from <something>path import *
dospath
posixpath
macpath
nturl2path
ntpath
macurl2path
filecmp
fileinput
StringIO
cStringIO
glob
fnmatch
posixfile
stat
statcache
statvfs
tempfile
shutil
pipes
popen2
commands
dl
fcntl
lowlevel
socket
select
terminal
termios
pty
tty
readline
syslog
serialize
pickle
cPickle
shelve
xdrlib
copy
copy_reg
threads
thread
threading
Queue
mutex
ui
curses
Tkinter
cmd
getpass
internal
_codecs
_locale
_tkinter
pcre
strop
posix
users
pwd
grp
nis
sgi
al
cd
cl
fl
fm
gl
misc (what used to be sgimodule.c)
sv
unicode
codecs
unicodedata
unicodedatabase
exceptions
os
types
UserDict
UserList
user
site
locale
pure
formatter
getopt
signal
pprint
========== Modules not handled ============
errno
resource
operator
struct
--
Moshe Zadka <mzadka(a)geocities.com>.
http://www.oreilly.com/news/prescod_0300.htmlhttp://www.linux.org.il -- we put the penguin in .com
Greg Ward writes:
> Distutils is now available through the Python CVS tree *in addition to
> its own CVS tree*. That is, if you keep on top of developments in the
> Python CVS tree, then you will be tracking the latest Distutils code in
> Lib/distutils. Or, you can keep following the Distutils through its own
> CVS tree. (This is all done through one itty-bitty little symlink in
> the CNRI CVS repository, and It Just Works. Cool.)
Greg,
You may want to point out the legalese requirements for patches to
the Python tree. ;( That means the patches should probably go to
patches(a)python.org or you should ensure an archive of all the legal
statements is maintained at CNRI.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
Hi all --
Distutils is now available through the Python CVS tree *in addition to
its own CVS tree*. That is, if you keep on top of developments in the
Python CVS tree, then you will be tracking the latest Distutils code in
Lib/distutils. Or, you can keep following the Distutils through its own
CVS tree. (This is all done through one itty-bitty little symlink in
the CNRI CVS repository, and It Just Works. Cool.)
Note that only the 'distutils' subdirectory of the distutils
distribution is tracked by Python: that is, changes to the
documentation, test suites, and example setup scripts are *not*
reflected in the Python CVS tree.
If you follow neither Python nor Distutils CVS updates, this doesn't
affect you.
If you've been following Distutils CVS updates, you can continue to do so
as you've always done (and as is documented on the Distutils "Anonymous
CVS" web page).
If you've been following Python CVS updates, then you are now following
most Distutils CVS updates too -- as long as you do "cvs update -d", of
course. If you're interested in following updates in the Distutils
documentation, tests, examples, etc. then you should follow the
Distutils CVS tree directly.
If you've been following *both* Python and Distutils CVS updates, and
hacking on the Distutils, then you should pick one or the other as your
working directory. If you submit patches, it doesn't really matter if
they're relative to the top of the Python tree, the top of the Distutils
tree, or what -- I'll probably figure it out. However, it's probably
best to continue sending Distutils patches to distutils-sig(a)python.org,
*or* direct to me (gward(a)python.net) for trivial patches. Unless Guido
says otherwise, I don't see a compelling reason to send Distutils
patches to patches(a)python.org.
In related news, the distutils-checkins list is probably going to go
away, and all Distutils checkin messages will go python-checkins
instead. Let me know if you avidly follow distutils-checkins, but do
*not* want to follow python-checkins -- if lots of people respond
(doubtful, as distutils-checkins only had 3 subscribers last I
checked!), we'll reconsider.
Greg
Does anyone else besides me have trouble getting their Python tree to sync
with the CVS repository? I've tried all manner of flags to "cvs update",
most recently "cvs update -d -A ." with no success. There are still some
files I know Fred Drake has patched that show up as different and it refuses
to pick up Lib/robotparser.py.
I'm going to blast my current tree and start anew after saving one or two
necessary files. Any thoughts you might have would be much appreciated.
(Private emails please, unless for some reason you think this should be a
python-dev topic. I only post here because I suspect most of the readers
use CVS to keep in frequent sync and may have some insight.)
Thx,
--
Skip Montanaro | http://www.mojam.com/
skip(a)mojam.com | http://www.musi-cal.com/
