Mailman 3 December 1999 - Python-Dev

distutils-sig/python-dev crosstalk
by Greg Ward Dec. 16, 1999

Dec. 16, 1999

Most recent threads on distutils-sig seem to have migrated to python-dev pretty quickly. This means that a) there are python-dev people on distutils-sig (duh), b) they think what goes on there is important enough to interest the other core developers (good!), and c) they assume there are people on python-dev who are not also on distutils-sig. Is this last assumption true? If you read python-dev, are interested in distutils issues, but do *not* read distutils-sig, please drop me a note. If … [View More]

2 2

Re: [XML-SIG] Developer's Day
by Paul Prescod Dec. 16, 1999

Dec. 16, 1999

"Andrew M. Kuchling" wrote: > > * Python revisions come out slowly, once every year or two. XML > standards have been revolving faster , and we don't want to wait > until 1.7 for SAX2, or DOM Level2, or other new revisions. > Keeping the modules out of the core lets them be updated at their > own pace. A counterargument is that the XML specs are slowing > down -- add namespace support to SAX, and finalize DOM > Level 2, and I don't think … [View More]any other standards are very important > to basic XML programming. I agree with your counterargument. :) Anyhow, isn't there a logical fallacy in your original argument? Why can't we offer a DOM 3 module or extension after Python ships with DOM 2? > * We really want a C-based parser to be commonly available. > sgmlop is the only reasonable choice for this, because I'd be > against including Expat. To replay some arguments I made against > including the zlib library in 1.6, what if a C extension requires > a newer version of the library? Symbol conflicts if you're lucky, > hard-to-debug problems if you're not. I don't understand this issue. Why would a C extension build on sgmlop which is designed to make XML information available to *Python* programmers? > * We can drop various marginal bits of the CVS tree; the xmlarch > support is probably not of very wide interest, for example. How about "expat", "mac", "pyexpat", "utils", "windows". There is just too much stuff there! And I daresay that alot of it has not been "quality controlled" to the level that we would expect if it were a part of the real Python library. In other words, there is no single place to go to get only XML-processing software that works well and works together. > I think I'm on the record as saying that Python's major problems now > aren't language-related, but are with the development environment. > Language changes (from minor, like 'for i in 1..9', to major, like > fixing the type/class dichotomy or adding static types) aren't going > to bring in piles of new users, useful though they might be to > experienced Pythoneers, large projects, or some other specific > application. (irrelevant aside: I agree 100% that making things easier to install will actually improve newbies experience more than (e.g.) static type checking but I do not agree that it is a better "sales tool". Most people are sold based on the language and its libraries before they start trying to install extensions.) > If installing things is a problem, then we need to > buckle down and finish the distutils. So, overall, I'd still vote > against inclusion in 1.6. So are you saying that Python 2 might have only five packages and everything else must be downloaded? No httplib, no pickle, no random or math, no calendar, pwd, grp, imaplib, nntplib, mailbox or rexec? When people download Python and go to the library documentation that impressive array of BUILT-IN-FEATURES is part of what sells them on Python. Hell, I can download all of that stuff for Scheme but what makes Python beautiful is that I don't have to download it for Python. It's just there. But if an XML person comes to Python after hearing us rant about how great it is for processing XML and all they find is xmllib...they will be underwhelmed. > No, it's *got* to reach 1.0. The point of the package is that it's > exactly *one* thing to install that gives basic XML tools; you don't > need to chase down the SAX modules from Lars' page, PyExpat from > ftp.cwi.nl, sgmlop from pythonware.com, and so forth. If the > Distutils made it as easy as: > > python fetchpackage.py SAX PyExpat DOM sgmlop > <find PySAX's home site> > <download it> > <compile & install> > etc... > > then much of the need for a single package goes away, but, as you > point out, that isn't currently the case. I'm a little lost here. We need xmllib to continue because distutils doesn't do what we need yet but we don't need to put the stuff in the Python library because disutils will work well enough soon. But there is an important issue that disutils will not solve. One of the beautiful things about the Python library is that everything is at the same version level. When you install it you know that everything works together or else it WILL in the next patch level if you report the incompatibility. When the xml package gets versioned incompatibly with the Python library you don't have that safe feeling. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself Three things never trust in: That's the vendor's final bill The promises your boss makes, and the customer's good will http://www.geezjan.org/humor/computers/threes.html [View Less]

4 3

Re: [Python-checkins] CVS: python/dist/src/Modules posixmodule.c,2.120,2.121
by Skip Montanaro Dec. 16, 1999

Dec. 16, 1999

>>>>> "Greg" == Greg Stein <gstein(a)lyra.org> writes: Greg> On Thu, 16 Dec 1999, Guido van Rossum wrote: >> I don't think there's much of a need to worry about this. Why are >> you always bringing up this subject? No-one else that I know has >> ever had this concern... Greg> Somebody has to :-) Greg> Keeping the working set low is more efficient from a system Greg> standpoint. Not to mention the not-all-that-… [View More]

2 1

Re: [Python-checkins] CVS: python/dist/src/Modules posixmodule.c,2.120,2.121
by Fred L. Drake, Jr. Dec. 16, 1999

Dec. 16, 1999

[Note that Greg's message went to python-checkins since he responded to a checkin message, but I suspect he meant to change the header to point to python-dev. ;) If not, too bad!] Greg Stein writes: > But this means that your tables no long reside in "const" space. Yet More > Per-Process Memory... > > It would be nice to have those tables marked as "const". Perhaps; as Guido points out, there haven't been a lot of complaints about this issue. I will note that only the … [View More]

2 1

fwd. from Paul Prescod
by Andrew M. Kuchling Dec. 15, 1999

Dec. 15, 1999

This is a forwarded e-mail from the XML-SIG mailing list, in which Paul makes some good points. Some context: I've been arguing against adding more XML stuff to the base Python distribution, because 1) it's bloat for those people don't care about XML, and 2) the Distutils is supposed to fix this by making installing things easier. Paul's response, below, has shaken my conviction a bit (*only* a bit, though). If it's deemed valuable, perhaps the XML-SIG could concentrate on the minimal set of … [View More]parser + SAX + DOM that could be included in 1.6. Please join the XML-SIG to follow the specifics of this thread further, as it relates only to XML. As a more general philosophical question for python-dev: do we want to add things to 1.6 following the "batteries included" philosophy? Or should we wave in the direction of the distutils and say they'll fix the problem? (In which case they should be given high priority, as in "1.6 doesn't ship until they're done".) -- A.M. Kuchling http://starship.python.net/crew/amk/ And after all, why should I go to bed every night? Sleep is only a habit. -- Cornelius Van Horne Paul Prescod writes: >"Andrew M. Kuchling" wrote: >> >> Huh? There's obviously a good deal of stuff in there, some of it >> perhaps too esoteric, but I don't see where there's overlap. > >Well, there are several parsers and parser wrappers. How is a user >supposed to choose? And there is PyDOM, Minidom and qp_dom. > >> Or are >> you talking about Python tools in general, where there are 3 DOM >> implementations? (PyDOM, 4DOM, and ZDOM hiding inside Zope.) > >That too. > >> I lean against shoveling more stuff into 1.6; better to get the >> Distutils widely used, which makes it easier to install *all* Python >> extensions. > >I don't think that XML is any more of an "add-on" to a modern scripting >language than URL support or regular expression support. I'm in the >"batteries included" camp for this and several other reasons: > > * standard Python libraries may soon need XML support. If WebDAV takes >off then there should be a libWebDAV right alongside libftp and libhttp. >And libWebDAV will require XML > > * there is a difference between theory and practice. In theory, >distutils will be done soon and everything will be easy. In practice, it >is the end of 1999 and at every conference I have to install the XML sig >package on the machines of several people who haven't been able to get >it going themselves. In practice, we can't wait for distutils because >people are choosing their XML tools now. > >> >Ideally we would have one (or at most two!) implementation of each of >> >the major specs: >> >XML >SAX >Unicode >XPath >XPointer >XSLT >DOM >> >> Do you mean "one implementation of each in a single package", or "one >> implementation existing for Python, distributed separately"? > >With the possible exception of XSLT, one implementation of each *in >Python 1.6*. > >> We need to come up with a position paper for developer's day, stating >> what needs to be discussed. Suggestions? I'd propose focusing on >> getting the XML-SIG package to 1.0, but that's just an idea. > >I don't see how the XML-SIG package can ever get to 1.0. Anybody can >contribute code at anytime and thus far we've been totally flexible >about putting it in. I think that's great. It just won't ever lead to a >stable, carefully maintained, tightly interoperable package. Some of the >maintainers of the individual pieces have probably lost interest and >there is probably nobody that understands it all enough to integrate it >nicely. > >-- > Paul Prescod - ISOGEN Consulting Engineer speaking for himself > [View Less]

1 0

Writers wanted for Linux Journal Python special issue
by Guido van Rossum Dec. 15, 1999

Dec. 15, 1999

Linux Journal is preparing a special issue devoted to Python (actually more like a pullout section or whatever I think). They are looking for writers, e.g. to write a piece about Python's history and/or an introduction. And probably anything else Python related. If you're interested, please write to Marjorie Richardson <mlr(a)ssc.com>, who is coordinating. Also direct any questions to her. This is for the June issue which will be on newsstands mid-May and mailed to subscribers even … [View More]

1 0

CVS: python/dist/src/Modules posixmodule.c,2.116,2.117
by Fred L. Drake, Jr. Dec. 13, 1999

Dec. 13, 1999

Greg Stein writes: > I'm not very familiar with these APIs, but should you let go of the > interpreter lock when you call them? > (and for the other new funcs) None of these should be doing an I/O as far as I can determine. Whenever I get to getlogin() (which AMK & I decided should be included, based on the specs that /F pointed us to), I will release the interpreter lock for the getlogin_r() variant. I'm not sure I should release it for the non-reentrant getlogin(), however;… [View More]

1 0

confstr(), fpathconf(), pathconf(), sysconf()
by Fred L. Drake, Jr. Dec. 13, 1999

Dec. 13, 1999

I've just checked in bindings for these POSIX.1 and POSIX.2 functions, and thought I'd explain the interfaces for those who don't want to read the diffs. ;) These functions expect a "name" parameter (that's how it's described in the man pages and the O'Reilly book). The value for "name" is an integer that's defined in the system headers. The constants all have the form _XX_SOME_NAME where XX is PC for fpathconf()- and pathconf()-related names, SC for sysconf()-related names, and CS … [View More]

1 0

Thankyou for fsync :)
by Jim Fulton Dec. 11, 1999

Dec. 11, 1999

I found recently that I needed fsync and was pleasantly surprized to find that it is provided in the posix module, where available. Can I count on it staying in the posix module, when available, for the forseeable future? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)… [View More]

6 10

Re: [Python-Dev] Zip format (was: Questions about distutils strategy )
by Jack Jansen Dec. 11, 1999

Dec. 11, 1999

> Jack Jansen asks: > > > Is it possible nowadays to have two files with the same name but > > different paths (i.e. foo/bar.py and foo/spam/bar.py) in the same > > archive? > > Depends on how you do it. Apparently I mis-phrased my question, I'll try again. When people suggested to use zip format as the standard Python archive format I was a bit worried, becuase I've had it happen to me various times that I was unable to create a ZIP archive with two files … [View More]

10 18