Here's a little issue with the news gatewaying: If the n
Here's a little issue with the news gatewaying:
If the news server you're trying to get to is down, or is slow and having
problems mailman creates a lock file and doesn't unlock. The next time
(every 5 minutes in my case) the gateway attempts to run the lock files
are in place and it evidently fails. Is there anything I can do to clear
those lock files manually, or, more importantly, is there anyway that
mailman can be configured to time out, and remove its own lockfiles/
thanks.
"P" == Patriot room_maildev@bbs.pixel.citadel.org writes:
P> Here's a little issue with the news gatewaying: If the news
P> server you're trying to get to is down, or is slow and having
P> problems mailman creates a lock file and doesn't unlock. The
P> next time (every 5 minutes in my case) the gateway attempts to
P> run the lock files are in place and it evidently fails. Is
P> there anything I can do to clear those lock files manually, or,
P> more importantly, is there anyway that mailman can be
P> configured to time out, and remove its own lockfiles/Hmm, I'm not entirely sure I believe that. cron/gate_news has a try/finally that should force the release of the global gate_news lock when any error occurs. So the news->mail path should be safe.
The mail->news path is a little trickier because Mailman 2.0.x forks a child to do the delivery in that direction. The child will os._exit() without ever releasing the lock, but by the same token, no nntp exceptions should percolate to the parent, and the parent is the process owning the lock and thus making sure it gets released. Because the child process never needs to write to the MailList, it doesn't own the lock.
Note that this has changed a bit in Mailman 2.1, where mail->news is implemented by a completely separate queue. Thus there are no child processes needed, and the list is never locked by this queue. gate_news hasn't changed substantially in this regard in 2.1.
-Barry
On Tue, Mar 13, 2001 at 05:04:44PM -0500, Barry A. Warsaw wrote:
Note that this has changed a bit in Mailman 2.1, where mail->news is implemented by a completely separate queue. Thus there are no child processes needed, and the list is never locked by this queue. gate_news hasn't changed substantially in this regard in 2.1.
Barry? How far along the garden path *is* 2.1?
I've just gotten shot in the head with a 1000:1 slowdown on batch adds for send a welcome vs don't... along with one or two other items.
Time to bring them up? Or past...?
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
"JRA" == Jay R Ashworth jra@baylink.com writes:
JRA> Barry? How far along the garden path *is* 2.1?It's in alpha, and AFAIK isn't being used by anyone except for testing purposes. In fact there have been zero downloads from SF so I wonder if you all are just ignoring it, or if everyone uses CVS. :)
Still, I'm relatively confident that what's there mostly works (more confident about the new queuing stuff, less so about the i18n stuff).
JRA> I've just gotten shot in the head with a 1000:1 slowdown on
JRA> batch adds for send a welcome vs don't... along with one or
JRA> two other items.
JRA> Time to bring them up? Or past...?You can always bring them up, but the best place to record them for posterity is in the SF tracker. Put it in the feature requests tracker or bug tracker as appropriate. There's just too much chance that it'll get lost in my inbox.
Or use the wiki for discussion purposes if you want. The wiki already contains what I think I can get to for 2.1. I want to try to be conservative with changes because the i18n stuff really needs to get out there. Still, I think some of the changes I've made already will help get a bunch of new features into the code base.
I use the same approach for Python development -- new features are on the table until the first beta release. I'm trying to keep any changes to the underlying "database" off the table for 2.1 because I think that'll push 2.1 back too far. My best guess at the moment is that we might see a beta of 2.1 by May.
I'll be concentrating on several other projects over the next few weeks though, so Mailman hacking will be a spare-time affair. There's Python 2.1 to work on, and I'm committed to working on BSDDB support for ZODB. This latter may have good side benefits for Mailman 3.0.
There's also some talk about more focussed Mailman work for some clients, but I don't have much information about that at the moment.
-Barry
At 06:24 PM 3/13/01 -0500, you wrote:
"JRA" == Jay R Ashworth jra@baylink.com writes:
JRA> Barry? How far along the garden path *is* 2.1?
It's in alpha, and AFAIK isn't being used by anyone except for testing purposes. In fact there have been zero downloads from SF so I wonder if you all are just ignoring it, or if everyone uses CVS. :)
I know I work off the CVS tree, although I haven't had a chance to look at my changes vs. your changes to see if you missed anything out of what I fixed in the last go round... I never bother downloading anything from SF, since my tree is usually current.
On Tue, Mar 13, 2001 at 06:24:04PM -0500, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth jra@baylink.com writes: JRA> Barry? How far along the garden path *is* 2.1?
It's in alpha, and AFAIK isn't being used by anyone except for testing purposes. In fact there have been zero downloads from SF so I wonder if you all are just ignoring it, or if everyone uses CVS. :)
Still, I'm relatively confident that what's there mostly works (more confident about the new queuing stuff, less so about the i18n stuff).
Got it. I presume SF has release notes, as they're built, too?
JRA> I've just gotten shot in the head with a 1000:1 slowdown on JRA> batch adds for send a welcome vs don't... along with one or JRA> two other items. JRA> Time to bring them up? Or past...?You can always bring them up, but the best place to record them for posterity is in the SF tracker. Put it in the feature requests tracker or bug tracker as appropriate. There's just too much chance that it'll get lost in my inbox.
Noted.
Or use the wiki for discussion purposes if you want. The wiki already contains what I think I can get to for 2.1. I want to try to be conservative with changes because the i18n stuff really needs to get out there. Still, I think some of the changes I've made already will help get a bunch of new features into the code base.
Got it. Well, the code base is pretty clean looking, at least the parts I've gotten into, even if my understanding of python is not. Any internals doco written yet? Is their a second tier of hackers following the list?
And will Python 2 finally get around to showing not only the call but the *values* in tracebacks? :-)
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
"JRA" == Jay R Ashworth jra@baylink.com writes:
JRA> Got it. I presume SF has release notes, as they're built,
JRA> too?There's moderate release notes in the files view, and of course I try to keep the NEWS file up-to-date, at least with the gross user visible changes. As Thomas can tell you, I'm pretty anal about check-in messages, so when in doubt, cvs log is your best friend. :)
>> Or use the wiki for discussion purposes if you want. The wiki
>> already contains what I think I can get to for 2.1. I want to
>> try to be conservative with changes because the i18n stuff
>> really needs to get out there. Still, I think some of the
>> changes I've made already will help get a bunch of new features
>> into the code base.
JRA> Got it. Well, the code base is pretty clean looking, at
JRA> least the parts I've gotten into, even if my understanding of
JRA> python is not.Thanks! I recently read Richard Gabriel's book and while it was kind of inconsistent, the part I really liked is the idea that code should be habitable. As I concentrate on and rewrite various parts of the code base, I try to keep that in mind.
JRA> Any internals doco written yet? Is their a second tier of
JRA> hackers following the list?Thomas? :)
JRA> And will Python 2 finally get around to showing not only the
JRA> call but the *values* in tracebacks? :-)Oh man, you should have seen Ka-Ping Yee's cgi driver thingie. Among the /many/ cool things he demoed at IPC9 (and it seemed like he demoed a new cool thing every day) was a cgi driver much like Mailman's driver, but which provided an awesome traceback view with values, and probably more. I'm Cc'ing him because I doubt he's on this list. I'm hoping I can prod him into talking more about it. :)
It'd be way cool to adopt either for Python itself or for non-stealthy Mailman tracebacks.
-Barry
On Wed, Mar 14, 2001 at 12:20:16AM -0500, Barry A. Warsaw wrote:
As Thomas can tell you, I'm pretty anal about check-in messages, so when in doubt, cvs log is your best friend. :)
'Anal' is the right word! I transgressed once, I'll be sure to never do it again :)
JRA> Well, the code base is pretty clean looking, at JRA> least the parts I've gotten into, even if my understanding of JRA> python is not.
Note that Python is the easiest langauge in the world. Did you read the tutorial yet ? If you're already familiar with programming in some other language, it's easy to get into, and will teach you everything about the language itself. Most of the rest you'll want to learn eventually is library docs, but you can browse those on an as-needed basis.
JRA> Any internals doco written yet? Is their a second tier of JRA> hackers following the list?
Thomas? :)
I guess I count as a second tier :) I haven't written any documentation yet, because most of the code is well commented, or easy to follow. (But then again, Barry and I share some common ground there, both being python developers. I might just be used to his (possibly adopted) code style :)
If I had time, I could probably write up some documentation... but if I had time, I could fix a ton of bugs and misfeatures, too ;-P
JRA> And will Python 2 finally get around to showing not only the JRA> call but the *values* in tracebacks? :-)
Oh man, you should have seen Ka-Ping Yee's cgi driver thingie.
You can see Dr. Mad Ping's cgitb.py module in action at http://www.lfw.org/python. There's been talk (at a lunchtable at IPC9, so it is very likely to happen ;) about adding a plaintext version to the std. Python library for use with normal scripts. I'm definately for it :)
-- Thomas Wouters thomas@xs4all.net
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Thu, Mar 15, 2001 at 10:53:48AM +0100, Thomas Wouters wrote:
JRA> Well, the code base is pretty clean looking, at JRA> least the parts I've gotten into, even if my understanding of JRA> python is not.Note that Python is the easiest langauge in the world. Did you read the tutorial yet ? If you're already familiar with programming in some other language, it's easy to get into, and will teach you everything about the language itself. Most of the rest you'll want to learn eventually is library docs, but you can browse those on an as-needed basis.
Well, you can code python like C, or you can code it like python, just like perl 5. If it's coded like C, which much of this package is, I can follow it.
JRA> Any internals doco written yet? Is their a second tier of JRA> hackers following the list?Thomas? :)
I guess I count as a second tier :) I haven't written any documentation yet, because most of the code is well commented, or easy to follow. (But then again, Barry and I share some common ground there, both being python developers. I might just be used to his (possibly adopted) code style :) If I had time, I could probably write up some documentation... but if I had time, I could fix a ton of bugs and misfeatures, too ;-P
Noted. Well, I'll be digging anyway; I'll drop breadcrumbs.
JRA> And will Python 2 finally get around to showing not only the JRA> call but the *values* in tracebacks? :-)Oh man, you should have seen Ka-Ping Yee's cgi driver thingie.
You can see Dr. Mad Ping's cgitb.py module in action at http://www.lfw.org/python. There's been talk (at a lunchtable at IPC9, so it is very likely to happen ;) about adding a plaintext version to the std. Python library for use with normal scripts. I'm definately for it :)
Cool.
That Would Be Good.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
[ Apologies for the off-topicness, but Python can't be *totally* off topic, not on this mailinglist, can it ? :) ]
On Thu, Mar 15, 2001 at 11:29:26AM -0500, Jay R. Ashworth wrote:
Note that Python is the easiest langauge in the world. Did you read the tutorial yet ? If you're already familiar with programming in some other language, it's easy to get into, and will teach you everything about the language itself. Most of the rest you'll want to learn eventually is library docs, but you can browse those on an as-needed basis.
Well, you can code python like C, or you can code it like python, just like perl 5. If it's coded like C, which much of this package is, I can follow it.
Actually, Mailman is written in pretty standard Python. Pipermail is probably an example of the word's worst Python code, but the rest is pretty simple :) It might reflect a bit of C style because Barry does a fair bit of C coding, but Barry also used to do a lot of Java coding (or pretend to, anyway, on JPython :) so I'm not sure if that's true. Python isn't like Perl, you can't write it in *that* many different ways :)
Usually just in one, even. Even pipermail is fairly standard python code, if you refactor some of the functions and fix the whitespace usage.
-- Thomas Wouters thomas@xs4all.net
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Fri, Mar 16, 2001 at 12:16:58AM +0100, Thomas Wouters wrote:
[ Apologies for the off-topicness, but Python can't be *totally* off topic, not on this mailinglist, can it ? :) ]
I shouldn't think so... and it's not like this list has been swamped with traffic... I *still* haven't gotten an answer to *my* first question, asked last Friday... :-}
On Thu, Mar 15, 2001 at 11:29:26AM -0500, Jay R. Ashworth wrote:
Note that Python is the easiest langauge in the world. Did you read the tutorial yet ? If you're already familiar with programming in some other language, it's easy to get into, and will teach you everything about the language itself. Most of the rest you'll want to learn eventually is library docs, but you can browse those on an as-needed basis.
Well, you can code python like C, or you can code it like python, just like perl 5. If it's coded like C, which much of this package is, I can follow it.
Actually, Mailman is written in pretty standard Python. Pipermail is probably an example of the word's worst Python code, but the rest is pretty simple :) It might reflect a bit of C style because Barry does a fair bit of C coding, but Barry also used to do a lot of Java coding (or pretend to, anyway, on JPython :) so I'm not sure if that's true. Python isn't like Perl, you can't write it in *that* many different ways :)
Well, no, but you can swim in the Object Orientation, or you can tiptoe through it, and the code I've looked at doesn't look to horribly deep to me.
Except make_whatever in Utils; how do you get a hard newline in that damned routine? The template stuff is one of the weak spots in system operator documentation... and the templates could us a touch of work, too -- no offence to whomever's writing that is...
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
I like the Amish virus better...
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
"JRA" == Jay R Ashworth jra@baylink.com writes:
JRA> I shouldn't think so... and it's not like this list has been
JRA> swamped with traffic... I *still* haven't gotten an answer to
JRA> *my* first question, asked last Friday... :-}Right at the tail end of IPC9, so that's not too surprising. Do you mean
JRA> The doco says the site password will work anywhere... but it
JRA> doesn't seem to work as the "old password" for changing a
JRA> list password, and I can't find anywhere *else* to do that
JRA> either. Am I missing something, or is that really a bug?
JRA> I'm gonna check Jitterbug for that, too, during my search.I definitely can't reproduce this in 2.0.3 or 2.1. Works for me. Are you sure you've got the crypt module installed in your Python executable?
Or was it
[w.r.t. max chunks per day hack]
JRA> Will this approach cause locking problems, etc?It worries me because you're basically freezing all mail delivery on all lists for some fraction of an entire day. So while people will still be able to hit the cgi for this list (since the list is unlocked), no mail will flow through the system at all while you're in that sleep(). Note that while SMTPDirect for the actual mail delivery task can be configured to run multiple threads, qrunner itself is single threaded, and the message pipeline will block at SMTPDirect until it's done with its work.
Your qrunner lock could be broken during that time. Qrunner's lock by default is 10 hours, so say you only deliver one chunk per day. 10 hours from now cron will start another qrunner, the lock will get broken, and now you've got two qrunners stomping on each others toes. Badness.
[Aside: your bare "except:" isn't good Pythonic form. You should adorn that except with the most specific exception you expect to get. In this case AttributeError. Bare excepts should be reserved for the (very) rare case of framework wrappers, a la scripts/driver.]
A slightly different approach to take would be, if you exceed your max chunks per day threshold, break out of the deliver() function, setting the refused dictionary to contain all the recipients in chunks that are deferred. Set the error code to something in the 400 range (to indicate a temporary failure), and this will cause a SomeRecipientsFailed exception to be signaled to the delivery pipeline.
Then you should add a timestamp to the msgdata for when you processed this chunk and at the top of SMTPDirect.process(), simply return if the timestamp is less than your delay period.
Without testing it, that approach (or something like it) ought to work better.
I'd also suggest adding this as a feature request to the SourceForge feature request tracker, so it doesn't get lost.
Cheers, -Barry
On Fri, Mar 16, 2001 at 12:21:34AM -0500, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth jra@baylink.com writes: JRA> I shouldn't think so... and it's not like this list has been JRA> swamped with traffic... I *still* haven't gotten an answer to JRA> *my* first question, asked last Friday... :-}
Right at the tail end of IPC9, so that's not too surprising. Do you mean
Figured.
JRA> The doco says the site password will work anywhere... but it JRA> doesn't seem to work as the "old password" for changing a JRA> list password, and I can't find anywhere *else* to do that JRA> either. Am I missing something, or is that really a bug? JRA> I'm gonna check Jitterbug for that, too, during my search.I definitely can't reproduce this in 2.0.3 or 2.1. Works for me. Are you sure you've got the crypt module installed in your Python executable?
Nope. I'll check, but while I can *get into8 the list using the site password, *using it as the old password to set a new one* is rejected. *Using the list password* as the old one, however, appears to work.
But no, I meant...
Or was it [w.r.t. max chunks per day hack] JRA> Will this approach cause locking problems, etc?
It worries me because you're basically freezing all mail delivery on all lists for some fraction of an entire day. So while people will still be able to hit the cgi for this list (since the list is unlocked), no mail will flow through the system at all while you're in that sleep(). Note that while SMTPDirect for the actual mail delivery task can be configured to run multiple threads, qrunner itself is single threaded, and the message pipeline will block at SMTPDirect until it's done with its work.
SMTPDirect is called from underneath qrunnner?
<voice tone="small"> Oh. </voice>
Your qrunner lock could be broken during that time. Qrunner's lock by default is 10 hours, so say you only deliver one chunk per day. 10 hours from now cron will start another qrunner, the lock will get broken, and now you've got two qrunners stomping on each others toes. Badness.
Indeed. At what level would it be best to try and fix this? It's actually only one part of "braodcast list handling", but it's probably the most important.
[Aside: your bare "except:" isn't good Pythonic form. You should adorn that except with the most specific exception you expect to get. In this case AttributeError. Bare excepts should be reserved for the (very) rare case of framework wrappers, a la scripts/driver.]
Well, yeah, but the try is only 4 lines long, fercrissake... ;-)
A slightly different approach to take would be, if you exceed your max chunks per day threshold, break out of the deliver() function, setting the refused dictionary to contain all the recipients in chunks that are deferred. Set the error code to something in the 400 range (to indicate a temporary failure), and this will cause a SomeRecipientsFailed exception to be signaled to the delivery pipeline.
Yeah, but *that* required that I understand all kinds of theory of operation that I, well, don't. :-) And it's inelegant, anyway.
Is this the exposing of an architectural deficiency in this part of the system? :-)
Without testing it, that approach (or something like it) ought to work better.
I'd also suggest adding this as a feature request to the SourceForge feature request tracker, so it doesn't get lost.
Noted. I'll try to figure out what other requirements using it this way engenders, and make it one big request.
Is there at least a call-tree somewhere? Or, alternatively, some code I can run against the system, specifying entry points, to create one?
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
"JRA" == Jay R Ashworth jra@baylink.com writes:
JRA> Well, no, but you can swim in the Object Orientation, or you
JRA> can tiptoe through it, and the code I've looked at doesn't
JRA> look to horribly deep to me.Python's very cool that way. It makes OOP about as simple as it can possibly be. In fact, I think Python would make a wonderful first or OOP teaching language. Jeez, at least much better than C++ or Java.
JRA> Except make_whatever in Utils; how do you get a hard newline
JRA> in that damned routine?You mean Utils.maketext()? You could set raw=1 which says not to pass the text to wrap(), and then your template would have to be properly wrapped already (if it's a plaintext file), or you'd include <p>'s and <br>'s if it's html.
The rules for wrap() are pretty simple. Paragraphs are always filled unless the line begins with whitespace. Blank lines separate paragraphs. That's it.
But I'll admit that wrap() is a bear of an algorithm, and I fear, too fragile to muck with. Still it does the job. Usable, human-friendly "structured" plaintext is a /hard/ problem, as anybody who's played with Wiki's StructuredText stuff will attest too.
JRA> The template stuff is one of the weak spots in system
JRA> operator documentation... and the templates could us a touch
JRA> of work, too -- no offence to whomever's writing that is...I completely agree.
-Barry
On Fri, Mar 16, 2001 at 12:29:08AM -0500, Barry A. Warsaw wrote:
"JRA" == Jay R Ashworth jra@baylink.com writes:
Have I mentioned that I hate that quoting style? :-)
JRA> Well, no, but you can swim in the Object Orientation, or you JRA> can tiptoe through it, and the code I've looked at doesn't JRA> look to horribly deep to me.Python's very cool that way. It makes OOP about as simple as it can possibly be. In fact, I think Python would make a wonderful first or OOP teaching language. Jeez, at least much better than C++ or Java.
Yeah, well, that dictionary stuff kinda lost me. I guess I'll get it, from looking at working code...
JRA> Except make_whatever in Utils; how do you get a hard newline JRA> in that damned routine?You mean Utils.maketext()? You could set raw=1 which says not to pass the text to wrap(), and then your template would have to be properly wrapped already (if it's a plaintext file), or you'd include <p>'s and <br>'s if it's html.
The rules for wrap() are pretty simple. Paragraphs are always filled unless the line begins with whitespace. Blank lines separate paragraphs. That's it.
But I'll admit that wrap() is a bear of an algorithm, and I fear, too fragile to muck with. Still it does the job. Usable, human-friendly "structured" plaintext is a /hard/ problem, as anybody who's played with Wiki's StructuredText stuff will attest too.
Ah. Ok. Yeah, I ended up indenting one space the stuff I didn't want wrapped.
JRA> The template stuff is one of the weak spots in system JRA> operator documentation... and the templates could us a touch JRA> of work, too -- no offence to whomever's writing that is...I completely agree.
Noted. It's not an easy problem, as I found out when I tried rewriting some of them. More When I Know More.
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
"TW" == Thomas Wouters thomas@xs4all.net writes:
TW> 'Anal' is the right word! I transgressed once, I'll be sure to
TW> never do it again :)>> JRA> Any internals doco written yet? Is their a second tier of
>> JRA> hackers following the list?
>> Thomas? :)
TW> I guess I count as a second tier :)Yeah, but it'll only take you a couple of days to reach the top tier and pass us all, if you haven't already. (Bloating Thomas's head so he'll take on the rewrite of the archiver, heh, heh. :)
TW> I might just be used to his (possibly adopted) code style :)All (good) Python coding styles derive from Guido's, naturally, and the beautify of Python is that there isn't a /whole/ lot of room for deviation (of any consequence).
<tangent> Does this stiffle creativity in Python programmers? Absolutely not, IMO. What it does is enforce a structure so that the creativity blossoms in the important dimensions. I used to maintain the C++ editing mode for Emacs, and the depths of, er, creativity in coding styles there was obnoxious. Guido recognized that code is read orders of magnitude more often than it is written, and Python encourages a community standard so that almost everyone can read almost everyone else's code. It's a wonderful breath of fresh air because Python becomes like a hammer in your hands -- almost invisible, an extension of your body. The tool disappears and you are left with just the task at hand. </tangent>
Still, I have my own minor deviations from Guido's style, and I think it's important to maintain consistency within a module, and within an application. That's why != is better than <> in the standard library, but not in Mailman code. :)
[Aside: A fun thing to do for IPC 10 would be to grab representative code samples from a wide range of prolific Python program and ask Guido to "name that hacker". He'd have no problem with mine, I'm __sure. :) ]
TW> [ Apologies for the off-topicness, but Python can't be
TW> *totally* off topic, not on this mailinglist, can it ? :) ]Naw, plus it's fun to talk about our passions, and Python definitely is one of mine (it better be or I guess I'd have to start looking for a new job). Plus, I suspect there's a lot of folks on this list that aren't (yet :) Python programmers, so explaining why we love it can't hurt.
TW> It might reflect a bit of C style because Barry does a fair
TW> bit of C codingAnd in former lives, such dinosauric languages as C++, ObjC, FORTH, Perl, Tcl, Smalltalk, assembly, SNOBOL, Pascal, PL1, BASIC, FORTRAN, blah, blah, blah. :)
TW> but Barry also used to do a lot of Java coding (or pretend to,
TW> anyway, on JPython :)Funny guy, that Thomas.
TW> so I'm not sure if that's true. Python isn't like Perl, you
TW> can't write it in *that* many different ways :)
TW> Usually just in one, even. Even pipermail is fairly standard
TW> python code, if you refactor some of the functions and fix the
TW> whitespace usage.Ah ha! Now you've done it. This is a clear offer from you to rewrite Pipermail. Nope, you can't back out now. We all heard it.
:)
i'll-even-give-you-a-week-ly y'rs, -Barry
participants (5)
-
barry＠digicool.com -
Jay R. Ashworth -
Ron Jarrell -
room_maildev＠bbs.pixel.citadel.org -
Thomas Wouters