Re: [Python-Dev] email package status in 3.X
[copied to pydev from email-sig because of the broader scope]
Well, it looks like I've stumbled onto the "other shoe" on this
issue--that the email package's problems are also apparently
behind the fact that CGI binary file uploads don't work in 3.1
(http://bugs.python.org/issue4953). Yikes.
I trust that people realize this is a show-stopper for broader
Python 3.X adoption. Why 3.0 was rolled out anyhow is beyond
me; it seems that it would have been better if Python developers
had gotten their own code to work with 3.X, before expecting the
world at large to do so.
FWIW, after rewriting Programming Python for 3.1, 3.x still feels
a lot like a beta to me, almost 2 years after its release. How
did this happen? Maybe nobody is using 3.X enough to care, but
I have a feeling that issues like this are part of the reason why.
No offense to people who obviously put in an incredible amount of
work on 3.X. As someone who remembers 0.X, though, it's hard not
to find the current situation a bit disappointing.
--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
> -Original Message-
> From: l...@rmi.net
> To: "R. David Murray"
> Subject: Re: email package status in 3.X
> Date: Sun, 13 Jun 2010 15:30:06 -
>
> Come to think of it, here was another oddness I just recalled: this
> may have been reported already, but header decoding returns mixed types
> depending upon the structure of the header. Converting to a str for
> display isn't too difficult to handle, but this seems a bit inconsistent
> and contrary to Python's type neutrality:
>
> >>> from email.header import decode_header
> >>> S1 = 'Man where did you get that assistant?'
> >>> S2 = '=?utf-8?q?Man_where_did_you_get_that_assistant=3F?='
> >>> S3 = 'Man where did you get that =?UTF-8?Q?assistant=3F?='
>
> # str: don't decode()
> >>> decode_header(S1)
> [('Man where did you get that assistant?', None)]
>
> # bytes: do decode()
> >>> decode_header(S2)
> [(b'Man where did you get that assistant?', 'utf-8')]
>
> # bytes: do decode(), using raw-unicode-escape applied in package
> >>> decode_header(S3)
> [(b'Man where did you get that', None), (b'assistant?', 'utf-8')]
>
> I can work around this with the following code, but it
> feels a bit too tightly coupled to the package's internal details
> (further evidence that email.* can be made to work as is today,
> even if it may be seen as less than ideal aesthetically):
>
> parts = email.header.decode_header(rawheader)
> decoded = []
> for (part, enc) in parts: # for all substrings
> if enc == None:# part unencoded?
> if not isinstance(part, bytes): # str: full hdr unencoded
> decoded += [part] # else do unicode decode
> else:
> decoded += [part.decode('raw-unicode-escape')]
> else:
> decoded += [part.decode(enc)]
> return ' '.join(decoded)
>
> Thanks,
> --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)
>
>
> > -Original Message-
> > From: l...@rmi.net
> > To: "R. David Murray"
> > Subject: Re: email package status in 3.X
> > Date: Sat, 12 Jun 2010 16:52:32 -
> >
> > Hi David,
> >
> > All sounds good, and thanks again for all your work on this.
> >
> > I appreciate the difficulties of moving this package to 3.X
> > in a backward-compatible way. My suggestions stem from the fact
> > that it does work as is today, albeit in a less than ideal way.
> >
> > That, and I'm seeing that Python 3.X in general is still having
> > a great deal of trouble gaining traction in the "real world"
> > almost 2 years after its release, and I'd hate to see further
> > disincentives for people to migrate. This is a bigger issue
> > than both the email package and this thread, of course.
> >
> > > > 3) Type-dependent text part encoding
> > > >
> > > ...
> > > So, in the next releases of Python all MIMEText input should be string,
> > > and it will fail if you pass bytes. I consider this as email previously
> > > not living up to its published API, but do you think I should hack
> > > in a way for it to accept bytes too, for backward compatibility in the
> > > 3 line?
> >
> > Decoding can probably be safely delegated to package clients.
> > Typical email clients will probably have str for display of the
&g
Re: [Python-Dev] email package status in 3.X
hon world today. If funding had been as stringent a prerequisite in the 90s, I doubt there would be a Python today. It was about the fun and the code, not the bucks and the bureaucracy. As far as I can recall, there was no notion of creating a task force to get things done. Of course, this may just be the natural evolutionary pattern of human enterprises. As it is today, though, the Python community has a formal diversity statement, but it still does not have a fully functional 3.X almost two years after the fact. I doubt that I'm the only one who sees the irony in that. Again, I mean no disrespect to people contributing to Python today on so many fronts, and I have no answers to offer here. For better or worse, though, this is a personal issue to me too. After spending much of the last 2 years updating the best selling Python books for all the changes this group has seen fit to make, I believe I can say with some authority that 3.X still faces a very uncertain future. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email package status in 3.X
> Python 3.0 was *declared* to be an experimental release, and by most > standards 3.1 (in terms of the core language and functionality) was a > solid release. > > Any reasonable expectation about Python 3 adoption predicted that it > would take years, and would include going through a phase of difficulty > and disappointment... Declaring something to be a turd doesn't change the fact that it's a turd. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. That's not a problem, unless you drop the word "beta". And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as "experimental", and promised a phase of "disappointment". Why would you expect the Python world to react any differently? > Whilst I agree that there are plenty of issues to workon, and I don't > underestimate the difficulty of some of them, I think "half-baked" is > very much overblown. Whilst you have a lot to say about how much of a > problem this is I don't understand what you are suggesting be *done*? I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] email package status in 3.X
I wasn't calling Python 3 a turd. I was trying to show the strangeness of the logic behind your rationalization. And failing badly... (maybe I should have used "tar ball"?) What I'm suggesting is that extreme caution be exercised from this point forward with all things 3.X-related. Whether you wish to accept this or not, 3.X has a negative image to many. This suggestion specifically includes not abandoning current 3.X email package users as a case in point. Ripping the rug out from new 3.X users after they took the time to port seems like it may be just enough to tip the scales altogether. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: Michael Foord > To: l...@rmi.net > Subject: Re: [Python-Dev] email package status in 3.X > Date: Fri, 18 Jun 2010 18:27:46 +0100 > > On 18/06/2010 18:22, l...@rmi.net wrote: > >> Python 3.0 was *declared* to be an experimental release, and by most > >> standards 3.1 (in terms of the core language and functionality) was a > >> solid release. > >> > >> Any reasonable expectation about Python 3 adoption predicted that it > >> would take years, and would include going through a phase of difficulty > >> and disappointment... > >> > > Declaring something to be a turd doesn't change the fact that > > it's a turd. > > Right - but *you're* the one calling it a turd, which is not a helpful > approach or likely to achieve *anything* useful. I still have no idea > what you are actually suggesting. > > > I have a feeling that most people outside this > > list would have much rather avoided the difficulty and > > disappointment altogether. > > > > Let's be honest here; 3.X was released to the community in part > > as an extended beta. > > Correction - 3.0 was an experimental release. That is not true of 3.1 > and future releases. > > All the best, > > Michael > > That's not a problem, unless you drop the > > word "beta". And if you're still not buying that, imagine the sort > > of response you'd get if you tried to sell software that billed > > itself as "experimental", and promised a phase of "disappointment". > > Why would you expect the Python world to react any differently? > > > > > >> Whilst I agree that there are plenty of issues to workon, and I don't > >> underestimate the difficulty of some of them, I think "half-baked" is > >> very much overblown. Whilst you have a lot to say about how much of a > >> problem this is I don't understand what you are suggesting be *done*? > >> > > I agree that 3.X isn't all bad, and I very much hope it succeeds. And > > no, I have no answers; I'm just reporting the perception from downwind. > > > > So here it is: The prevailing view is that 3.X developers hoisted things > > on users that they did not fully work through themselves. Unicode is > > prime among these: for all the talk here about how 2.X was broken in > > this regard, the implications of the 3.X string solution remain to be > > fully resolved in the 3.X standard library to this day. What is a > > common Python user to make of that? > > > > --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > > > > > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, > clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and > acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with > your employer, its partners, licensors, agents and assigns, in perpetuity, > without prejudice to my ongoing rights and privileges. You further represent > that you have the authority to release me from any BOGUS AGREEMENTS on behalf > of your employer. > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
Stephen J. Turnbull wrote (giving me an opening to jump in here): > R. David Murray writes: > > In other words, my proposed patch only makes email5 1/8 to 1/4 > > broken, instead of half broken as it is now. But not un-broken > > enough for Mailman, it sounds like. > > IMO, not in the long run. But realistically, in the applications I > know of, most desired traffic is conformant, and since there aren't > any Python 3 email apps yet, this isn't even a regression. :-/ Well, yes there are, and yes it is. As I pointed out in a thread on this list back in June, there are multiple large Python 3 email "apps" in the new Programming Python, a book which is about to be released, and which will be read by at least tens of thousands of people, many of whom will be evaluating the stability of Python 3. These apps include both a simple webmail site, as well as a more sophisticated 5k-line tkinter email client -- one which I've been using for all my personal and business email over the last 6 months, and which works well with the email package as it is in 3.1 (albeit with a bit of workaround code). This includes support for Unicode, MIME, headers, attachments, and the lot. I'm forwarding a link to the code of these clients to David by private email in case they might be useful as a test case (O'Reilly has already posted them ahead of the book, but they may be a bit too heavy for use in formal testing). The email package is obviously less than ideal today, and there are many other clients for it besides my own, of course. But making it backward incompatible at this point is likely to be seen as a big negative to newcomers evaluating 3.X viability. And as I tried to make clear in June, this list should carefully weigh the PR cost of pulling the rug out from under those brave souls who have already taken the time to accommodate the 3.X world you've mandated. To put that more strongly, the Python user base is much larger than this list's readership. If I'm using 3.1 email, so are many others. People will accept the 3.X world you make up to a point, but it's impossible to code to a moving target, much less base a product on it. At some point, they'll simply stop trying to keep up; in fact, some already have. Fixes are a Good Thing, of course, and this particular change's scope remains to be seen; but to channel most of the users I meet out there in the real world today: Enough with the 3.X changes already, eh? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
Thanks for both your reply and work, David. I'm going to have to test my email clients under the 3.2 patch when it gels. It's good to hear that email5 API support remains a goal. I don't mean to single out this change unfairly, of course. My real concern is not as much with the specific technical aspects of this proposal, as with the generally low priority that backward compatibility sometimes receives on this list. The bytecode file model change in 3.2 comes to mind as another example; sound as it may be, I'm not sure this list has any idea how many users, systems, or docs may be impacted by this. Though not always true, the work here does sometimes appear to be conducted in a vacuum. Ultimately, development in the open source world is driven by the very few with time to show up, rather than by the very many who depend on it. This can unfortunately lead to the perception of thrashing by end users. Some even come to see the net effect as not that much different from closed models. I have no solution to offer, except to underscore again that changes made here affect very many people who are too busy using Python to participate here. Especially given the still tentative state of 3.X, stability matters. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: "R. David Murray" > To: l...@rmi.net > Subject: Re: [Python-Dev] Patch making the current email package (mostly) > support bytes > Date: Thu, 07 Oct 2010 13:46:02 -0400 > > On Thu, 07 Oct 2010 16:03:18 -, l...@rmi.net wrote: > > I'm forwarding a link to the code of these clients to David by > > private email in case they might be useful as a test case (O'Reilly > > has already posted them ahead of the book, but they may be a bit too > > heavy for use in formal testing). > > Thanks very much. I will take a look, and expect they will > be helpful. > > > The email package is obviously less than ideal today, and there are > > many other clients for it besides my own, of course. But making it > > backward incompatible at this point is likely to be seen as a big > > negative to newcomers evaluating 3.X viability. And as I tried to > > make clear in June, this list should carefully weigh the PR cost of > > pulling the rug out from under those brave souls who have already > > taken the time to accommodate the 3.X world you've mandated. > > Well, as I have said before the plan is to provide backward compatibility > in email6, so that you only need to change your code if you want to > take advantage of improved or new functionality. If this turns out not > to be possible for some reason, then we aren't going to suddenly stop > supporting email5. That's not the Python Way :) (Example: we added > ArgParse post-3.0, and lots of people wanted to deprecate OptParse, > but we aren't planning on removing OptParse.) > > Do you see any issues with the patch I'm proposing? My goal is to make > things work that didn't work before, but nothing that worked before > should stop working, if I do my job right. > > The one *potentially* backward-incompatible change that I'm consciously > considering (that is, any other backward incompatibilities will be bugs) > is having DecodedGenerator fully decode headers and emit full unicode, > rather than the ASCII-only unicode that Generator emits. Can you think > of any problem that that would cause? A quick grep indicates your own > code does not use that generator (possibly because currently it does not > do that decoding). I could, of course, only enable header decoding if > a flag is passed requesting it, and as I write this I realize that that > is indeed what I should do. Even though I haven't been able to think of a > case where DecodedGenerator producing non-ASCII unicode would be an issue, > that doesn't mean there isn't one :) > > > To put that more strongly, the Python user base is much larger than > > this list's readership. If I'm using 3.1 email, so are many others. > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > Now that Python3 is out, the backward compatibility policy for it is > the same as it always was for Python2. Only the transiti
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
step...@xemacs.org wrote in the full message below: > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. But I _did_ come here and articulate my needs, and received this antagonistic response for my efforts. If you really value user input, you may want to explore the nature of your reaction to it. Trust me: criticism goes with the territory any time your actions impact a large group of people. This seems inherent here. Frankly, your view of the roles of developers and users seems so upside down to me that I doubt anything I could say here would matter. You're more than welcome to ignore an interjection of reality and adopt a closed group mindset, of course, but you do so at the peril of the system you're working on. For my part, one week from now I'll be standing up again in front of a group of 20 Python beginners, and basically apologizing for both the present and ongoing 3.X changes they must conform to in the near future. Python may not be Perl 6 yet, but its image is already tarnished in the real world where people make technology choices, due to its rapid pace of change. It's a genuine problem. In the end, I suppose I'm just one of those lazy end users you mentioned who are too busy to spend 24/7 hanging out on this list in order to head off changes that will break their code. (Yes, sarcasm intended.) --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > -Original Message- > From: "Stephen J. Turnbull" > To: l...@rmi.net > Subject: Re: [Python-Dev] Patch making the current email package > (mostly)support bytes > Date: Fri, 08 Oct 2010 14:33:22 +0900 > > l...@rmi.net writes: > > > To put that more strongly, the Python user base is much larger than > > this list's readership. > > Agreed. Nevertheless, this is the channel (not "channel") that the > developers listen on, and substantial effort is made to let Python > users know that. I think they do know it, too. > > > If I'm using 3.1 email, so are many others. > > That's not obvious. 3.1 email is unusable for several applications. > In fact, for human factors reasons (humans are very likely to > communicate with other humans who use the same encodings, and to > accept occasional glitches they must deal with manually), MUAs are > likely to port relatively easily as "good enough" software. But I > doubt very much that folks writing MTAs or spam filters that must run > unattended, often in long-lived, very active processes, are producing > production versions using Python 3 email yet. > > > People will accept the 3.X world you make up to a point, but it's > > impossible to code to a moving target, much less base a product on > > it. > > "Impossible is nothing." It's a decision that each individual > developer makes for herself. I haven't heard Mailman devs complain > about the impossibility of dealing with the proposed changes, for > example. Quite the reverse, in fact. > > > At some point, they'll simply stop trying to keep up; in fact, > > some already have. > > Predictable and predicted. Where's the balance? I don't know, but > "channeling" the users is not a lot of help. There are three worthy > goals here: > > 1. Taking advantage of improvements in to-be-released Pythons. > 2. Not changing one's own working code. > 3. Not participating in python-dev/email-sig. > > Take any two; one can't have all three. > > More specifically, it's interesting that most of the users you talk to > care enough to actually say they don't want more incompatible changes. > But what are we supposed to take from that? Some fixes have to be > incompatible; do the users want the fix or the compatibility? You > waffle (as a good representative often must): > > > Fixes are a Good Thing, of course, and this particular change's scope > > remains to be seen; but to channel most of the users I meet out there > > in the real world today: Enough with the 3.X changes already, eh? > > But that's also a decision each developer *can* make for himself. > Python does not withdraw products, or even withdraw support, just > because the core developers release something they consider better. > > If having 1 *and* 2 is so important to particular users, but they come > into conflict because of proposed changes in Python, then they're > going to have to give up 3, come here, and articulate their needs. As > you are doing -- but to have real influence, you're going to have to > do the review of David's patch that he requests. > > I really don't see how the process can work any other way. > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
ba...@python.org wrote in the full post below: > I'm reminded of a survey Guido conducted at some long past > Python conference. He asked (paraphrasing): raise your hand > if you think Python is changing too fast. Lots of hands went > up. Then he asked, raise your hand if you have a feature you > want to get in the next version. Lots of hands went up. When? I doubt that you'd get the same reaction today given the schism that 3.X has created. Regardless, this underscores much of what I'm trying to get across here. Python conference attendees are hardly representative of the user base at large. Even today, they are probably just 0.1% of the whole. This list's readership is an order of magnitude smaller still. Open doesn't mean all that much to those outside the 0.01% whose preferences set the agenda. I appreciate that some people here do indeed weigh compatibility carefully, and realize that there are multiple valid viewpoints on this issue. And regrettably, I have neither solutions nor time to give this thread the further attention it deserves. So my point is just this: Change for change's sake is truly not what most Python users want. If Python core developers want 3.X to become as popular as 2.X, they should be less concerned with posts on this list or hands at a conference, than with the feet of the masses whose votes will ultimately decide 3.X's fate. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > Date: Fri, 8 Oct 2010 14:20:32 -0400 > From: Barry Warsaw > To: python-dev@python.org > Subject: Re: [Python-Dev] Patch making the current email package (mostly) > support bytes > > On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote: > > >Ultimately, development in the open source world is driven by the > >very few with time to show up, rather than by the very many who > >depend on it. This can unfortunately lead to the perception > >of thrashing by end users. Some even come to see the net effect > >as not that much different from closed models. I have no solution > >to offer, except to underscore again that changes made here affect > >very many people who are too busy using Python to participate here. > >Especially given the still tentative state of 3.X, stability matters. > > I'm reminded of a survey Guido conducted at some long past Python conference. > He asked (paraphrasing): raise your hand if you think Python is changing too > fast. Lots of hands went up. Then he asked, raise your hand if you have a > feature you want to get in the next version. Lots of hands went up. > > I'm sympathetic to the view that changes in Python can be disruptive to end > users. The Python community itself takes this seriously too, as evidenced by > the language moratorium[*]. But OTOH, Python cannot stagnate and even fixing > things means changing things. The reality too is that Python releases come > out approximately every 18 months, and a year and a half can either seem like > an excruciatingly long time, or blink of the eye depending on which side of > the fence you stand on. > > Yes, stability matters, but Python 3 is still a new snakeling and I suspect > that as the pace of porting picks up, more changes will be necessary. Adding > new modules named like distutils2 or unittest2 is less than satisfying but > useful for keeping older APIs around. > > I'm sad to hear that some people think that our development model differs > little from closed source development. To me, nothing could be further from > the truth. But the adage does go "(s)he who does the work, decides", and this > is the forum for those who are doing the work. I think everyone here welcomes > advocates for under-represented Python communities, and their concerns should > be taken in consideration when changes are discussed. But ultimately, Python > must evolve to stay relevant or it will die. This is where competing design > trade-offs must be discussed. If not here, by us, then where and by whom? > > -Barry > > [*] Mostly instituted to allow alternative implementations to catch up, it > does necessarily slow the pace of changes visible to end users. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Continuing 2.x
Kristj?n Valur J?nsson writes: > James Y Knight said: > The python community has already decided many times over that Python2 is dead > and Python3 is the future > > But the patient is very much alive and kicking, no matter what the good > doctor > declares. Python 2.x is in widespread use, with gazillion lines of .py code. > > In, there is another gazillion lines of .c and .cpp code both in extensions > and > embedding applications in use. I?m quite happy with the community at large > moving its development focus to 3.x but it is a bit harsh to deprive those > left > behind of the keys to the old house. Exactly. Has anyone here analyzed download stats on py.org lately? Please feel free to prove me wrong, but by my reckoning, and at least for Windows MSI installer files, people are still downloading Python 2.X roughly 3 to 4 times more often than Python 3.X today, some 2 years after 3.X's release. This is from http://www.python.org/webstats for September and October, based on file size and bytes fetched for all significant versions. As one metric, roughly 439K people fetched 2.X MSI files in September, and 124K went for 3.X. Granted, there are plenty of variables such as preinstalled Pythons on Macs and Linux, though many would tend to skew 2.X dominance even higher. Moreover, downloads may be more reflective of new users, than existing users who are likely in the 2.X camp. But clearly, the 2.X patient is hardly dead; it still reflects the vast majority of the Python world today. I hope 3.X use expands; in fact, I've bet the future of at least one book on it. And even 1/4 of new users seems a large enough subset to care about too. But one can't help but wonder if most of the development community is focused on some imaginary future user base, at the expense of the much larger current user base. Then again, there's still plenty of Fortran77 code out there, so... --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
