From mhammond@skippinet.com.au Fri Oct 1 01:27:03 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 1 Oct 1999 10:27:03 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us> Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat> OK - general agreement. Wheee :-) How about this: def getopt_or_die(opts, long_opts=[], usage=None, prog_name=None, args=None, exit_code = 1): if usage is None, we build a very simple usage string from opts/long_opts. If prog_name is None, we use os.path.basename(sys.argv[0]). This is printed just before the usage message. If args is None, we use sys.argv[1:] exit_code specifies the param to sys.exit() on invalid options. I have based the ordering on my guess at the most likely to be used - but maybe "prog_name" and "args" should be reversed? This should _not_ be all-singing, all-dancing, as it is simple to use the existing getopt.getopt() directly for more esoteric requirements; the old 80-20 rule applies here :-) If the general agreement continues, I will then knock together an implementation. Mark. From gward@cnri.reston.va.us Fri Oct 1 01:51:37 1999 From: gward@cnri.reston.va.us (Greg Ward) Date: Thu, 30 Sep 1999 20:51:37 -0400 Subject: [Python-Dev] getopt helper? In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000 References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat> Message-ID: <19990930205136.A14297@cnri.reston.va.us> On 01 October 1999, Mark Hammond said: > OK - general agreement. Wheee :-) > > How about this: > > def getopt_or_die(opts, > long_opts=[], > usage=None, > prog_name=None, > args=None, > exit_code = 1): > > if usage is None, we build a very simple usage string from > opts/long_opts. I still think it would be very desirable to tie the short and long options together. Eg. options = [('verbose', 'v'), ('quiet', 'q'), ('thingy', None), (None, 'x') ('output=', 'o:')] opts, args = getopt_or_die (options, usage, ...) Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x', and 'value' -- never 'v', 'q', or 'o' (Look, I restrained my tendency to invent type systems and auto-generate help text. There may be hope for me yet.) Greg From tim_one@email.msn.com Fri Oct 1 06:55:46 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 1 Oct 1999 01:55:46 -0400 Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr> Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim> [Vladimir Marangozov, plugging] > Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating > Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978. Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, perhaps? it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim From mhammond@skippinet.com.au Sun Oct 3 08:52:59 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sun, 3 Oct 1999 17:52:59 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <19990930205136.A14297@cnri.reston.va.us> Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat> Greg writes: > I still think it would be very desirable to tie the short and long > options together. Eg. > > options = [('verbose', 'v'), > ('quiet', 'q'), > ('thingy', None), > (None, 'x') > ('output=', 'o:')] > opts, args = getopt_or_die (options, usage, ...) > Im not convinced this is worth it. I only use "long options" when I have too many, or a few obscure ones. I have never have "-v" synonymous for "--verbose" - why bother? I know I would never type the later:-) The existing mechanism still handles this quite well - the standard "if opt==blah:" simply becomes "if opt in [...]:" - no real drag. Plus its less change for reasonable reward - handy enough I may actually add command-line handling as I create each little test/util script :-) What say anyone else? Go with my "little change", Gregs "only slightly more change" or "don't worry about it"? Mark. From skip@mojam.com (Skip Montanaro) Sun Oct 3 15:26:54 1999 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT) Subject: [Python-Dev] getopt helper? In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat> References: <19990930205136.A14297@cnri.reston.va.us> <001a01bf0d74$5031ed80$0801a8c0@bobcat> Message-ID: <14327.26542.101415.144270@dolphin.mojam.com> Mark> Im not convinced this [pairing up long and short options] is worth Mark> it. The primary reason where it would be helpful is to generate clearer default usage strings. Aside from that, I'm not sure the extra structure would be worth it. Skip From jeremy@cnri.reston.va.us Sun Oct 3 18:05:18 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT) Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim> References: <199909181417.PAA20866@pukapuka.inrialpes.fr> <000101bf0bd1$9b1cf5a0$842d153f@tim> Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us> >>>>> "TP" == Tim Peters writes: TP> [Vladimir Marangozov, plugging] >> Saltzer J., "Naming and Binding of Objects", in Bayer R., >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, >> 1978. TP> Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, TP> perhaps? Indeed he was. TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim I think sixth degrees of separation only made sense in the pre-email world. These days it's probably down to four or five. Jeremy From mhammond@skippinet.com.au Mon Oct 4 00:30:25 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Mon, 4 Oct 1999 09:30:25 +1000 Subject: [Python-Dev] ESR on slashdot Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat> Just as a matter of interest, here is a question put to ESR and his answer. We certainly could do alot worse than to have ESR becoming a real Python advocate :-) If only Guido himself could find time to work on 1.6, we would be "in like Flynn" :-) Mark. shawnhargreaves asks: You've always been involved in hacker projects outside of just coding (eg. the Jargon File), but over the last year or so the spokesperson role seems to have grown into a fulltime job. How long is it since you last sat down to write a major piece of software? Do you expect to go back to fulltime development work anytime soon, and if so, what would you work on? How do you manage to cope with the withdrawal symptoms? ESR answers: An astute question ;-). I haven't sat down to write a major piece of software from scratch in months, but I am continuing to maintain fetchmail. I just took over the gif2png beta code with Greg Roelofs's consent; the 1.0.0 version might be out by the time you read this. Today I did some work on gnuplot, bringing the PNG driver up to date. If I get to go full-time again soon, I want to go back to work on Trove, the distributed web-based code-archiving system I designed last year. I'd also like to work with Guido van Rossum on Python 1.6; there are some long-time wishlist features like rich comparisons and a full lambda facility that I care enough about to implement myself. I also have a strategy-gaming system I wrote back in the 1980s that I'd like to put a modern (Web-based) interface on. Finally, having contributed a bit of code to GNOME (the network-monitor applet) I'd like to balance things by doing something for KDE. From gstein@lyra.org Mon Oct 4 10:51:53 1999 From: gstein@lyra.org (Greg Stein) Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT) Subject: [Python-Dev] Alternative Approach to Relative Imports In-Reply-To: <37F21B2F.DD65738F@interet.com> Message-ID: On Wed, 29 Sep 1999, James C. Ahlstrom wrote: > "M.-A. Lemburg" wrote: > > I know, but there still is no way to query what kind of hooks > > are already loaded and what is worse, you cannot unload or reorder > > them. > > I think this is a valid point. I am interested in hooks to read > modules from a file archive. If you are a developer, it is > necessary to turn this hook OFF, so that you can revert to the > usual directory tree where your current source is. > > I am solving this by leaving a global variable "Importer" in > sitecustomize, and calling sitecustomize.Importer.enable(0). > This works, but it might be useful if imputil could de-install > a hook as well as install it. It was a design point to not provide this functionality. It is pretty difficult to unhook the importers from the chain. I specifically said, "well... when you alter the import behavior, then it will stay that way." I figured this was entirely safe since an Importer could have an enable/disable flag like you implemented, or my (theoretical) Import Manager could pull an Importer out of its list that it was managing. I'm not sure that we want an Import Manager to always be installed in the hooks, but it could be a good idea to have a standard manager in the library somewhere (which Importers could state a dependency upon its installation). Cheers, -g -- Greg Stein, http://www.lyra.org/ From jim@interet.com Mon Oct 4 16:16:28 1999 From: jim@interet.com (James C. Ahlstrom) Date: Mon, 04 Oct 1999 11:16:28 -0400 Subject: [Python-Dev] Alternative Approach to Relative Imports References: Message-ID: <37F8C4CC.6C230B06@interet.com> Greg Stein wrote: > It was a design point to not provide this functionality. It is pretty > difficult to unhook the importers from the chain. I specifically said, > "well... when you alter the import behavior, then it will stay that way." > > I figured this was entirely safe since an Importer could have an > enable/disable flag like you implemented, or my (theoretical) Import > Manager could pull an Importer out of its list that it was managing. I think my design of leaving a global "Importer" instance variable in imputil is a bit lame. Each importer is a class instance, but I don't see a list of importers in imputil. Suppose impuil kept a list of installed importers imputil.ImporterList[]. Then to access an importer I have installed, I can write: for im in imputil.ImporterList: if isinstance(im, MyImporter): im.enable(0) It would not be necessary to dis-install an importer, imputil would just undertake to keep a list of installed importers, and if someone wanted to control their installed importers, they would use the list. I do not feel too strongly about this. Maybe it is a good idea. What do you think? I can just use my global variable I guess. Jim Ahlstrom From fredrik@pythonware.com Wed Oct 6 10:52:55 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 6 Oct 1999 11:52:55 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> http://www.cobolscript.com/ "[COBOL's] just a language whose superiority for developing certain types of modern systems has been overlooked until now" PROCEDURE DIVISION. 0000-MAIN. DISPLAY WEB-PAGE-HEADER. ACCEPT DATA FROM WEBPAGE. COMPUTE grand_total = subtotal *(1 sales_tax_rate). DISPLAY WEB-PAGE-BODY. DISPLAY WEB-PAGE-FOOTER. well, why not? :-) From jack@oratrix.nl Wed Oct 6 12:02:39 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 06 Oct 1999 13:02:39 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Message by "Fredrik Lundh" , Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> > http://www.cobolscript.com/ > > "[COBOL's] just a language whose superiority for > developing certain types of modern systems has > been overlooked until now" The whole site sort-of makes me wonder whether this is one big elaborate joke. But if it is somebody put an incredible amount of work in it. The funny thing is that the idea of using Cobol for web-programming _did_ initially strike me as a neat idea: because of the elaborate data descriptions and report generation facilities you could conceivably use all that info to automatically generate all the input forms and such. But they have apparently done no such thing... The timesheet example is, uhm, interesting. 1500 lines of code, with many parameters hardcoded in the source. I'd be surprised if it would take more than 100 lines in Python, with a lot more customizability too. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@CNRI.Reston.VA.US Wed Oct 6 15:57:21 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 10:57:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us> > X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10) > X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET > OVERLEEFD! Ach! Wish I was there! > > http://www.cobolscript.com/ > > > > "[COBOL's] just a language whose superiority for > > developing certain types of modern systems has > > been overlooked until now" > The whole site sort-of makes me wonder whether this is one big > elaborate joke. But if it is somebody put an incredible amount of > work in it. Definitely a joke. Try http://www.cobolscript.com/csfaq.htm#question9 "One of the other advantages of COBOL is that COBOL file processing statements are very simple, with no knowledge of disk head positioning required." But yes, an incredibly good one! Worth filling out the form on the "contact us page" and seeing what they send back. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm@hypernet.com Wed Oct 6 17:55:18 1999 From: gmcm@hypernet.com (Gordon McMillan) Date: Wed, 6 Oct 1999 12:55:18 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us> References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <1272894334-31005071@hypernet.com> [Guido, on http://www.cobolscript.com/] > Definitely a joke. Try > > http://www.cobolscript.com/csfaq.htm#question9 > > "One of the other advantages of COBOL is that COBOL file > processing statements are very simple, with no knowledge of disk > head positioning required." > > But yes, an incredibly good one! Worth filling out the form on > the "contact us page" and seeing what they send back. While funny, I can virtually guaruntee these people are serious. It is a common misperception among mainframe/COBOL types that C/Unix has *only* character I/O (which does not exist in the former environment at all - even terminals are block I/O). They regard this as a sign of their vast superiority. (And I dearly wish that born-again "Windoze" bashers be sentenced to work in this environment - they'll soon realize how closely related Windows and Unix are). I did a number of stints introducing client / server to Big Blue shops. (Unix made it's entry *only* because RDBMS's ran on them, and all these shops claimed they would dump Unix as soon as these products worked right on big iron). I *always* had an endless fight with the people who wanted to use COBOL instead of C / C++ (on both the Unix boxes and the PCs). MicroFocus distributed a "white paper" comparing COBOL to C that I came to know very, very well. It came in 4 sections: - the Executive Summary said COBOL was vastly superior in all respects - the White Paper said COBOL was more maintainable (translation - you can hire brown-nosing dorks in suits, instead of geeks in T-shirts) and often had superior performance - the Benchmark showed that C smoked COBOL in absolutely everything except binary search (a COBOL builtin) - the Appendix showed that the C code for "binary search" was a very badly coded linear search. But no shop had ever read past the Executive Summary. And don't forget that there is probably more than one order-of- magnitude more COBOL source out there than source in any other (or maybe all other) language(s). All with no built-in date type; and hardly ever using common date routines either (calling external programs in COBOL is expensive, and awkward, because all variables are global). Y2K-compliant-by-omission-ly y'rs - Gordon From guido@CNRI.Reston.VA.US Wed Oct 6 18:00:50 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 13:00:50 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT." <199910061457.KAA08749@eric.cnri.reston.va.us> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> <199910061457.KAA08749@eric.cnri.reston.va.us> Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us> Now I'm confused... I typed in the comment box: Very good joke. ROFL. Where do you guys find the time and energy to do this! :-) and got this back: Mr. van Rossum Glad you took the time out of your busy schedule to berate us. We must be doing something right! ;) Chuck Shereda Deskware, Inc. www.deskware.com www.cobolscript.com --Guido van Rossum (home page: http://www.python.org/~guido/) From klm@digicool.com Wed Oct 6 18:19:30 1999 From: klm@digicool.com (klm) Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT) Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us> Message-ID: On Wed, 6 Oct 1999, Guido van Rossum wrote: > Now I'm confused... I typed in the comment box: > > [...] > and got this back: > > Mr. van Rossum > > Glad you took the time out of your busy schedule to berate us. > We must be doing something right! ;) > > Chuck Shereda > Deskware, Inc. > www.deskware.com > www.cobolscript.com Apparently deskware is a known, bona fide organization. Considering the massive number of cobol programmers around, and despite how cumbersome the prospect is (and with the advantage of factoring in the things gordon said), i guess someone thinks there's leverage in making cobol a scripting language. I think it's not so different than making interpreted versions of C (but i'm not very C friendly). Ken klm@digicool.com From klm@digicool.com Wed Oct 6 19:05:21 1999 From: klm@digicool.com (Ken Manheimer) Date: Wed, 6 Oct 1999 14:05:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com> Concerning the possibility of cobolscript, i wrote: > said), i guess someone thinks there's leverage in making cobol a scripting > language. I think it's not so different than making interpreted versions > of C (but i'm not very C friendly). After posting i thought this might come off as more ignorantly bigoted than i meant for it to seem:-) I was trying to say that C doesn't seem very well suited to scripting/running interpreted, like cobol - not that C is as fraught with ancient and awkward design as cobol (seems). Sigh. Ken klm@digicool.com From mal@lemburg.com Mon Oct 11 21:36:07 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 11 Oct 1999 22:36:07 +0200 Subject: [Python-Dev] Walking up the package hierarchy Message-ID: <38024A37.D92E7091@lemburg.com> This is a multi-part message in MIME format. --------------8F8110B6CFB57E279F385677 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody, while I'm still thinking about writing the import manager, here is a patch that implements the walk-up-the-hierarchy import scheme that got so much positive feedback. I'm intending to use this implementation as proof of concept for the switch to my new package structure, but wouldn't mind seeing something like it the distribution as well ;-) It changes the default import mechanism to work like this: >>> import d try a.b.c.d try a.b.d try a.d try d fail instead of just doing the current two-level lookup: >>> import d try a.b.c.d try d fail As a result, relative imports referring to higher level packages work out of the box without any ugly underscores in the import name. Plus the whole scheme is pretty simple to explain and straightforward. Since the patch is so small, I attached it to this mail. Hope you don't mind. The ZIP archive also contains a sample package which demonstrates the feature. Run Python with -v flag to see how the new scheme works. Feedback is most welcome. I am especially interested whether the scheme breaks any existing packages. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 81 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ --------------8F8110B6CFB57E279F385677 Content-Type: application/x-zip-compressed; name="walkingimport.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="walkingimport.zip" UEsDBAoAAgAAAASgKiejNvGqNwAAADcAAAANABUAYS9fX2luaXRfXy5weVVUCQADJ0fZN/ND AjhVeAQA9AFkAApwcmludCAnSW5pdCBtb2R1bGUgJXMsIHBhdGg9JXMnICUgKF9fbmFtZV9f LF9fcGF0aF9fKQpQSwMEFAACAAgADq4vJ7lAUhN3AAAA1QAAAAcAFQBhL2FiLnB5VVQJAAMM +N8380MCOFV4BAD0AWQAjc5BCsMgEIXh/ZxiNmE0SG7QA/QMpQyaShFGDWoXIeTuXWhW3XQ3 8H4+BrYSUkO6p9Aw5tdHPE6VcELFnGz0zBogxC2Xhg7gLdlZqXhDyWs/jhM6wtw7ZkV2cWRG bHpqHk89yjFc2rKKt0Xpfx2a6Ye6fqx7hS9QSwMEFAACAAgAGp8vJzpfQHVJAAAASgAAAA8A FQBhL2IvX19pbml0X18ucHlVVAkAA+Td3zfzQwI4VXgEAPQBZAAVyEsKgCAUBdD5W8WdiAVO WoALaBUXQyPBH/raf3SGR8bMTWHPlhW1x7ckmOUwgj7eLAuDjWyhJtKRf5O7SOkhpsh79soL Hod8UEsDBBQAAgAIALKtSyehIXVYrAAAAEsBAAAJABUAYS9iL2JjLnB5VVQJAANfPgI480MC OFV4BAD0AWQAbc5BDoIwEAXQfU/xgyGoix7AxAO4caVxSQYYgdh2TFsk3l5UMBFdzeL/lz/q 6lsXke1cG2Gl6gwjDRlSLPPckeU8Xyk1lg7+3roarb2Kj5DzBKjAdgvSw9VaZ2osUPGRJ0Zo pDMVnPRo6DagsuQQEAUTe3efaoG9eEsGXaCa0b9kwRt19mJB+B04hudnyTxP0DNqjvOBP0rC xNbfap6O2EhJJixX+sL34Sj1AFBLAwQUAAAACACmsEsnju+MVhAGAACcEAAAEwAVAHdhbGtp bmdpbXBvcnQucGF0Y2hVVAkAA/dCAjj3QgI4VXgEAPQBZACNV3tv00gQ/9v9FENOR5M6zqNQ ShIFUR3tgQSlAg5OgpO1STaJr37den0lOvW738zOruO8oFFV27szs/P4zWODIICblV5maTdK 8kzpztS7UhFc5ApgAP3BsNcbnvXxZTA48n0fussskd1YJpNSLbq50NOlnHVZRNDvnHVOff9O xLdRumCB3W3x77IU3k819PtwejrsPR32zlj8y5cQ9M+e9dunffD55Tng4kLqMBdKprq5iLOJ iIs2TMp5G/IQH7FMW0dwfwRHUGihoyna837yt8QTTo4gzsQsTOV33UyyWRtErM0zD1ORyF0x 3poX6UZHQW2BeUfQPYHLSC+lgusslZApKFAWiAJwG066R/5+putMQ1nIGYh0lWRKdogWvOlS KDg5YY1G1QKqRB9RikKcgrjwX0VA5DCGHcYZHjNGV6jpUjXZyuPOccsJYzGWNh9tmKxkUcYa 19AEVPhTBom4lRB8EXEMS5Hnq06nwxayXXiQcZOPK9Ecmjer8LNUk6yQV7FYtHDVyxWeOm82 flmHYgjNfgtItfHxr8UxRkEU0n52Torjb2mjTazAP2ND5YM2Plp0IpgTjbVjuP7j7duWcY5n HQK8SAZ6yMYuwRfjEuMNhIwn40IiGyPv+bP20zNC3uBJe3BOyHsoeuiQm9WlUuFHqT9qNHmB vrj8Pg0/i7iUuJGpNhF5XuMyyfWK3FbG0tjWMNp4SupSpZXSBOjAy1FvPAX8OggCY3kOj8xe C7/RaEzNMQW62vaRNiDeF2N4d/HnzcWn128vr8lJwUOUDYyy79Zqgs4ydEi6IH2DLX0D1Dfw 0MPpNF818zYHjcBmiPOv+PYXKfitZzSsrMG1SlPcwC0GIa5zwQiLcsLO4hjkxu0tZ6ajHmPW hyYfHz+2cSL/4KOyOHx1+duHyyvLwkYgyl9LJV1oISkLDRPJmS3SGVSLabbewAwwDjikaIUT /ONzaqo+YmCSnusVq7zV1ZAnQt2GSVQUTbKXiHq07Xt3ywhDQilEXyapXQKF7NEaVigzycqL PJdoDpYtaBKgW3UEQo7BNXvzEjPdLEWpTUGCkEn5/WD0vS004sIGHB3BYTwSx88BSVQ/QCRt b0ASF+7p3wFQkj2bqPS9Q7D0nRF76tuBAnfasrCAChbAxa5huGxta5DDq0roCp/bzatix0H8 IuHNNWHYwBI7ELmAa3RR4kekqQWuChAqKzHas5J8SYG1sVzrYrsxfFpGBZb2ggQhvGcE7yJK pxLuHBNyRHNTseAO+15WagTHVMkEG7IVj0iewxTP1A40Ms7ubKug1GO1KYPZ9Q9Ncr+euI7b RWMn9y2YrPdcz52TL6hxUUYZbSmr2tQPopxRH6UiRtu1ljPnfwOwucoSQ+ESzNQEhJlaOa8S rY200IaWEADLaEETQi6mt2IhEXP/yriKLSqvTfTQ96j2CDL6vIsKROdcRLHxMx7l6CVlgPMm FwcubzW7TXPZU+R8TpxD6D2E3yctU/GM7yCwoF3D1k54ULIDl5FUAgeOFSKYo7Y+9WAdO6Sw 2dhOZZvMLHKj3L2oy8MjvtZ3N7Ibf9VwZKYj0795OKofQUPBBn1Ni+2Zw9LVC0dvtCOmvk3c AXBdcSpX+1v60mlr3hebnqsNqpg4hWWx23YRCCNvOMd+l5qL56toqpuVpy2cmHrTqj1R8Hjq u1mREBL5RsvE1mwrxZVqz7WP7aPqA5sl3S7/bp3hxs3g46rAsza6gd1v3JjbgWtpBLZo3RX2 23F/KOTOQJNZTM1Edlb0f4RbtuMqU4nQtoex9zfUZqWvs3oPnsGvndNer2hwm+KZcGcq9Myc tW5qBsGbsxYjamve2oSgvQMYWfc7gxQjYGfCOzRw/XC++pk/ggd7Y1sf3wZkn+77ZoEqwhMl xa2bsMHRVVcfWjXXgfP+oN3v4XXg/Px5u/+UrgP7mxV+cgRcL28Zwdh9Psh/ykjJIX5x1Xfg R7cNHR8tOE4mJFWHRNsJzUUjDHHkanQa+H8/DzWGh9zAtvWvdLD3sL3DiC35zsrKyJGxks5s Jj+rCGvXtNz8i7ABvjZVw8H2rex/UEsBAhYDCgACAAAABKAqJ6M28ao3AAAANwAAAA0ADQAA AAAAAQAAAKSBAAAAAGEvX19pbml0X18ucHlVVAUAAydH2TdVeAAAUEsBAhYDFAACAAgADq4v J7lAUhN3AAAA1QAAAAcADQAAAAAAAQAAAKSBdwAAAGEvYWIucHlVVAUAAwz43zdVeAAAUEsB AhYDFAACAAgAGp8vJzpfQHVJAAAASgAAAA8ADQAAAAAAAQAAAKSBKAEAAGEvYi9fX2luaXRf Xy5weVVUBQAD5N3fN1V4AABQSwECFgMUAAIACACyrUsnoSF1WKwAAABLAQAACQANAAAAAAAB AAAApIGzAQAAYS9iL2JjLnB5VVQFAANfPgI4VXgAAFBLAQIWAxQAAAAIAKawSyeO74xWEAYA AJwQAAATAA0AAAAAAAEAAACkgZsCAAB3YWxraW5naW1wb3J0LnBhdGNoVVQFAAP3QgI4VXgA AFBLBQYAAAAABQAFAGYBAADxCAAAAAA= --------------8F8110B6CFB57E279F385677-- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Oct 12 21:21:02 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT) Subject: [Python-Dev] string methods branch Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us> Guido has agreed to let me mainline the string methods branch. Those of you on python-checkins should have seen the CVS messages by now. This is a good thing because I think we can all agree we hate CVS branches. For me, that final merge put the nail in the coffin. Anyway, those of you who have put off playing with string methods until now should just be able to do a CVS update, rebuild, and go. You should read the revision log messages for the branch checkins for details of the changes. Let me know if you have any problems. Fred and I will work out changes to the documentation some time soon. >>> sig=['branches','are','only','useful','for','trees','and','streams','ly'] >>> print '-'.join(sig) + " y'rs" -Barry From skip@mojam.com (Skip Montanaro) Tue Oct 12 22:03:13 1999 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 12 Oct 1999 16:03:13 -0500 Subject: [Python-Dev] new opportunities for obfuscation... ;-) Message-ID: <199910122103.QAA31864@dolphin.mojam.com> Barry's note prompted me to update my Python tree. The result: >>> ".".join(dir("")) 'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper' A job well done, Barry... Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... From mal@lemburg.com Wed Oct 13 13:27:57 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 13 Oct 1999 14:27:57 +0200 Subject: [Python-Dev] Walking up the package hierarchy References: <38024A37.D92E7091@lemburg.com> Message-ID: <38047ACD.E716154E@lemburg.com> Strange... I would have thought that this new patch would stir up some cheers or opposition. Has anyone tried it in some real apps ? It would be interesting to see whether it breaks any code in e.g. packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't break anything for my packages or apps. > It changes the default import mechanism to work like this: > > >>> import d > try a.b.c.d > try a.b.d > try a.d > try d > fail > > instead of just doing the current two-level lookup: > > >>> import d > try a.b.c.d > try d > fail -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 79 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov@inrialpes.fr Thu Oct 14 12:26:11 1999 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT) Subject: [Python-Dev] Walking up the package hierarchy In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm" Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr> M.-A. Lemburg wrote: > > Strange... I would have thought that this new patch would stir up > some cheers or opposition. Has anyone tried it in some real apps ? Not yet, but this looks better as a default search path. > > It would be interesting to see whether it breaks any code in e.g. > packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't > break anything for my packages or apps. JimF, /F, Guido and other package maintainers could do you a favor by trying your patch ;-) and give us some real feedback on this. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Fri Oct 15 08:21:15 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 15 Oct 1999 03:21:15 -0400 Subject: [Python-Dev] Corporate installations Message-ID: <000401bf16dd$def75d80$d72d153f@tim> Python is getting used widely enough in my place of employment that people are agitating for a common installation (personal variants are screwing people too often). Various machines are running Win95, Win98, NT, Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke on that whole banana when it's shoved down my throat. For starters, I just need to get it running across Windows platforms. Never looked into this before, and it seems to be exceedingly complicated right out of the box <0.5 wink>: D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON'] >>> Where does all that stuff come from? The first is apparently the current directory; cool. The next 4 appear to come from MarkH's stuff, via the registry. The next 4 appear to come from Python's own registry PythonPath key. The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows -- case differences). The last is another mystery. site.py isn't implicated in any of them (same thing when running with -S). I suppose this is a clue: D:\Python>set PYTHONHOME=ick;fooey D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> sys.path ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'ick', 'fooey\\DLLs', 'ick', 'fooey\\lib', 'ick', 'fooey\\lib\\plat-win', 'ick', 'fooey\\lib\\lib-tk', 'D:\\PYTHON'] >>> Doesn't appear to be sensible, but at least it's predictable . I was surprised to find that setting PYTHONPATH can't be used to override any of this -- it just inserts even more stuff, into sys.path[1:1]. Do I really care? Not much -- the complexity just makes it hard to get a mental model of what Python *thinks* it's trying to accomplish here, and so harder to figure out what needs to be done. Which is pretty severe: "Dragon std" apps must run the same version of Python (which can be local) with the same libraries (which must be network-mounted), regardless of whatever version of Python each user may have built on their own, and regardless of their registry settings or envar values. I think this means I need to distribute a python15.dll and python.exe (via our source control system) into a directory very early on the PATH (other common .exe's are distributed this way, so no big deal), and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the common Dragon dir. Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK. There's no way to do that from within Python, is there? If not, everyone going through "unfortunate" paths in the network will have to set that themselves. Anyone have better ideas? That shouldn't be hard . the-difference-between-one-user-and-two-is-infinite-ly y'rs - tim From mhammond@skippinet.com.au Fri Oct 15 09:02:14 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 15 Oct 1999 18:02:14 +1000 Subject: [Python-Dev] Corporate installations In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat> > The 4 after that are a mystery, and duplicate the > preceding 4 (except > for meaningless-- it's Windows -- case differences). Python makes a brave attempt to deduce the PYTHONHOME itself by looking for "well-known" files in the lib directory. Python15.dll uses argv[0] or the result of GetModuleFileName(NULL) (whichever is deemed "better" by the existance of a slash) as the basis for a search for the landmark file. If found, those 4 entries are added and if not they are added relatively (ie ".\lib" in the vain hope they will suddenly become meaningful (which they almost certainly wont) So, when running a .EXE that lives in the main Python directory (such as Python.exe), we get duplicated entries - the ones we deduced, and the ones explicitely in the registry. The problem arises when Python15.dll is used by a .exe that doesnt live in this nice directory - eg Pythonwin, or any other embedding, such as COM objects or peoples custom apps. As argv[0] and GetModuleFileName(NULL) both return a directory where "\lib" appended will not find the landmark file (string.py for windows), you get the useless relative paths added. So, what this means is that Python's strategy for deducing the PythonPath only works for Python.exe and Pythonw.exe - typically the only .exes in the Python directory. So we have the situation where the paths must also be registered in the registry if any other .exe wants to work. > I was surprised to find that setting PYTHONPATH can't be used > to override > any of this -- it just inserts even more stuff, into sys.path[1:1]. Once upon a time Guido stated that PYTHONPATH should override the registry completely. I cant recall the history of this tho, and wouldnt object is that was the case. You are then faced with how to set this env variable (and if you are doing that, why not just set the registry?) > I think this means I need to distribute a python15.dll and > python.exe (via > our source control system) into a directory very early on the > PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC > paths, + the > common Dragon dir. This should be fine - as long as no one needs to run any other .EXE that needs Python15.dll (or unless that other .exe is also in that same directory). > Network name mangling being what it is, I suppose I'll also > need to force > PYTHONCASEOK. There's no way to do that from within Python, > is there? If While my views on this have temepered from illogically ranting to Guido how much I hate it, I still believe this is a mis-feature for Windows. The other alternative is to put Python.exe on the network path, and have your library in a ".\lib" directory under that. Doesnt really solve the problem for your "DragonLib" stuff - Im sure you dont want to stuff _everything_ into a single .lib directory. Also, IMO Python shouldnt bother going sniffing for its library if the registry exists. It just adds time to startup, and if it works is almost guaranteed to be redundant, and if it doesnt work will add useless entries that slow down module searches. However, that still doesnt solve your problem. The final suggestion is to put some of the win32 extensions (specifically, win32api) on a network share along with Python.exe and the standard lib. Then provide a .bat file that actually sets up the registry, and off you go. Sure, people hate the registry, but setting an environment variable is worse. Or an alternative - provide a .reg file with the necessary registry keys - users can "execute" it (double-clicking from explorer, typing the name in start->run, execute "start whatever.reg in their logon script, etc) to have their registry setup. I wish I had a better answer, but can't for the life of me work out what it should be even if MS supported it! Mark. From mal@lemburg.com Fri Oct 15 09:34:14 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 15 Oct 1999 10:34:14 +0200 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <3806E706.82FEB673@lemburg.com> Tim Peters wrote: > > Python is getting used widely enough in my place of employment that people > are agitating for a common installation (personal variants are screwing > people too often). Various machines are running Win95, Win98, NT, > Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke > on that whole banana when it's shoved down my throat. > > For starters, I just need to get it running across Windows platforms. Never > looked into this before, and it seems to be exceedingly complicated right > out of the box <0.5 wink>: > > D:\Python>python > Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import sys > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? The first is apparently the current > directory; cool. The next 4 appear to come from MarkH's stuff, via the > registry. The next 4 appear to come from Python's own registry PythonPath > key. The 4 after that are a mystery, and duplicate the preceding 4 (except > for meaningless-- it's Windows -- case differences). The last is > another mystery. site.py isn't implicated in any of them (same thing when > running with -S). On Linux I get: ['', '/home/lemburg/bin', '/home/lemburg/lib', '/home/lemburg/projects', '/home/lemburg/python/Lib/', '/home/lemburg/python/Lib/test', '/home/lemburg/python/Lib/plat-linux2', '/home/lemburg/python/Lib/lib-tk', '/home/lemburg/python/Modules', '/usr/local/lib/python1.5/site-packages'] It seems that the last entry refers to what Python thinks is the standard location for system wide extensions. The first 3 come from my PYTHONPATH setting, the next few are inserted by the Python startup code based on what Python found as landmark to determine PYTHONHOME. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the > common Dragon dir. Sounds reasonable ;-) > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. There's no way to do that from within Python, is there? If > not, everyone going through "unfortunate" paths in the network will have to > set that themselves. If Windows allows writing the process' environment you can set PYTHONCASEOK dynamically: the check queries the environment for the flag prior to every check (instead of doing going the usual internal Python flag way as many of the others do). See Python/import.c:check_case() for details. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 77 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim@interet.com Fri Oct 15 16:22:38 1999 From: jim@interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 11:22:38 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <380746BE.FAE46A0A@interet.com> Tim Peters wrote: > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? Good question. I don't know, and every time I start to think I do, I am wrong. Certainly PYTHONPATH is full of junk on Windows. The point is that PYTHONPATH just doesn't work for commercial installations. Please see these for some discussion: ftp://ftp.interet.com/bootmodule.html ftp://ftp.interet.com/pylib.html I think the solution is to put the library files and packages into archive files (in some format yet to be determined) and find them by looking in the directory of python15.dll and/or python.exe. On Unix there is $prefix, which actually seems to work. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH Yes, that is a good start. Just understand that *.pyd and and DLL's which are imported (instead of linked against) are found from PYTHONPATH, not PATH. Also you will need a valid PATH on all PC's which is quite a bother. An alternative is to use the Wise installer to set up icons for your apps. Real Windows apps don't use PATH. We use Wise for internal as well as external apps. Note that if you import a module "import foo", and foo lives in "foo.dll", then on Windows, PYTHONPATH is searched, and the standard Windows DLL path is not searched. That means you can't use standard Windows locations for DLL's which are dynamically imported. This is an error and should be fixed. > and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) The problem is that you already need a valid PYTHONPATH to find sitecustomize.py. Better is to create a custom python15.dll with sitecustomize.py, exceptions.py and site.py (all needed during boot) frozen in as frozen modules. In our office I freeze in other library files too. > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. I don't seem to need that on 95/98/NT. Network names shouldn't get mangled on these systems. I guess you mean lack of case sensitivity, but just make sure the case is correct in the Lib directory. This is another reason to prefer archive files anyway. But no, you shouldn't need PYTHONCASEOK. > Anyone have better ideas? That shouldn't be hard . Yes, this is a major problem with Python's acceptance for commercial apps (and I include internal production code as an app) so lets figure out what to do and fix it. Jim Ahlstrom From jim@interet.com Fri Oct 15 19:19:41 1999 From: jim@interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 14:19:41 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> Message-ID: <3807703D.9FD09C5B@interet.com> "James C. Ahlstrom" wrote: Sorry, correct URL is: ftp://ftp.interet.com/pub/bootmodule.html ftp://ftp.interet.com/pub/pylib.htm Jim Ahlstrom From fredrik@pythonware.com Fri Oct 15 20:17:05 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:17:05 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> while doing the final checks for my upcoming standard library guide, I thought I'd check what had changed in the CVS version. some old (1.5.1) junk was still to be found in the lib-old subdirectory, but certain 1.5.2 things seem to have vanished into thin air. like find.py, for example. does anyone know where it is? after all, it's kinda useful, and I just pointed someone to it, only to find that he didn't have it on his machine... is there an official list of totally deprecated modules somewhere? From Fred L. Drake, Jr." References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us> Fredrik Lundh writes: > some old (1.5.1) junk was still to be found in the > lib-old subdirectory, but certain 1.5.2 things seem > to have vanished into thin air. > > like find.py, for example. does anyone know > where it is? after all, it's kinda useful, and I It should be in lib-old. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fredrik@pythonware.com Fri Oct 15 20:58:17 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:58:17 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Fred L. Drake, Jr. wrote: > > like find.py, for example. does anyone know > > where it is? after all, it's kinda useful, and I > > It should be in lib-old. "should" as in "is already there" or "oops, I'll fix it" ? :-) [fredrik@brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/ CVS codehack.py newdir.py rand.py whatsound.py Para.py fmt.py ni.py tb.py zmod.py addpack.py lockfile.py poly.py util.py (sure looks like "oops" to me...) From Fred L. Drake, Jr." References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us> Fredrik Lundh writes: > "should" as in "is already there" or > "oops, I'll fix it" ? :-) It's certainly in lib-old/ in the CVS repository. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tismer@appliedbiometrics.com Fri Oct 15 22:55:36 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 15 Oct 1999 23:55:36 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com> "Fred L. Drake, Jr." wrote: > > Fredrik Lundh writes: > > "should" as in "is already there" or > > "oops, I'll fix it" ? :-) > > It's certainly in lib-old/ in the CVS repository. Sorry. Definately certainly not. But a find.py is in Demo/threads. Fred (any of both :) did you mean that? ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From fredrik@pythonware.com Mon Oct 18 08:31:16 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 18 Oct 1999 09:31:16 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> > > > "should" as in "is already there" or > > > "oops, I'll fix it" ? :-) > > > > It's certainly in lib-old/ in the CVS repository. > > Sorry. Definately certainly not. > > But a find.py is in Demo/threads. > Fred (any of both :) did you mean that? I cannot see any "find.py" in either Lib (where it is in all my copies of 1.5.2) or Lib/lib-old. fwiw, I can think of a few dozen other standard library modules that I'd remove before this one. cannot we put it back? please? :-) (after all, it's been a reoccuring theme on comp.lang.python lately. and 1.5.2+ breaks my new book...). From Fred L. Drake, Jr." References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us> Fredrik Lundh writes: > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It most certainly *should* be appearing in lib-old; I just checked the internal CVS repository and it's really there. Perhaps the anonymous mirror isn't right? (Barry, can you check this? I don't even know where it is, much less whether I can see those directories.) > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) That's up to Guido, not me. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From guido@CNRI.Reston.VA.US Mon Oct 18 15:56:55 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 18 Oct 1999 10:56:55 -0400 Subject: [Python-Dev] what happened to find.py? In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200." <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us> > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, we'll ask Barry to investigate. Maybe the branching messed things up? > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) It's better (and more illustrative) to use os.walk() to do this thing. > (after all, it's been a reoccuring theme on > comp.lang.python lately. and 1.5.2+ breaks > my new book...). Good thing it isn't printed yet. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Mon Oct 18 16:35:04 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> <199910181456.KAA22936@eric.cnri.reston.va.us> Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, Guido> we'll ask Barry to investigate. Maybe the branching messed Guido> things up? Somehow the mirror was out of date. Perhaps the branch merge got it out of whack, but in any case, I've done a top-level resync. find.py is definitely in the repository under lib-old now! Hope that helps, -Barry From ggr@qualcomm.com Tue Oct 19 16:30:01 1999 From: ggr@qualcomm.com (Barry A. Warsaw) Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT) Subject: [Python-Dev] forwarded message from Greg Rose Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Folks, I'm resending this message here for Greg Rose. If anybody can help him out, please respond to ggr@qualcomm.com (not to me). Greg, if you still get no response, then I suggest sending the mssage to greater python-list@python.org. There's gotta be /somebody/ out there who is interested in participating. -Barry ------- start of forwarded message (RFC 934 encapsulation) ------- From: Greg Rose To: bwarsaw@python.org Subject: Re: python advocate in Perl/Python/Tcl bakeoff Date: Tue, 19 Oct 1999 20:28:37 +1000 X-Sender: ggr2@avalon.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 17:07 30/09/1999 -0400, you wrote: >Hope that helps. If neither of these guys can do it, and can't >suggest someone who can, let me know and we'll post an announcement on >all the usual Python haunts. Well, as they say, those who volunteer end up doing things... I've tried both of your associates, and about three or four others who were recommended, and have struck out. I'd really appreciate your help trying to find someone competent to do this. Bear in mind that the audience is sysadmins, not generic programmers. thanks in advance, Greg. Here's the text I've been sending out, but you should feel free to modify non-factual stuff: Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX conference somewhere or other. It was fun for all involved, and was very well received. We're looking to do something similar at the LISA conference in Seattle. You have been recommended as Python advocate. It would be on thursday 11th november. The idea would be to have a moderator and three advocates, and a slightly rowdy audience. We'd ask each advocate to nominate in advance some simple sysadmin task which shows their language to its advantage, and also to do the solutions to the other two's tasks... then there'd be some room for (presubmitted) tasks from the audience to be solved on the fly. Any suggestions you have regarding how to make it work would be appreciated. Are you intending to attend LISA? Would you be willing to do this? (We have Tom Christiansen for perl and Brent Welch for Tcl/Tk.) Greg Rose INTERNET: ggr@Qualcomm.com Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C ------- end ------- From guido@CNRI.Reston.VA.US Tue Oct 19 16:49:10 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 19 Oct 1999 11:49:10 -0400 Subject: [Python-Dev] forwarded message from Greg Rose In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT." <14348.36473.112615.887932@anthem.cnri.reston.va.us> References: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us> Alas, I'll be at SD99 East in DC that week, teaching Python CGI programming. See http://www.python.org/Events.html --Guido van Rossum (home page: http://www.python.org/~guido/) From da@ski.org Tue Oct 19 17:58:34 1999 From: da@ski.org (David Ascher) Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Irrelevant but very informative piece of patent law Message-ID: http://slashdot.org/features/99/10/19/1032254.shtml Very well written, too. Many many standard deviations away from standard slashdot fare. --da From mhammond@skippinet.com.au Sat Oct 30 00:11:54 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Sat, 30 Oct 1999 09:11:54 +1000 Subject: [Python-Dev] Embedding Python when using different calling conventions. Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> This is a bit yucky, but still a valid problem. Malte Kroeger [kroeger@bigfoot.com] recently posted to python-help with a problem. He has an existing Windows project that he wishes to use Python in. This project does not use the standard __cdecl calling convention that Python uses, for various reasons known only to him. As it is an existing project and quite probably a large, complex one, I am willing to accept that moving his existing project to match Python's calling convention is not reasonable. I also feel for him, as I have personally battled this - both with Python and with other projects. He has requested that Python explicitely declare the calling convention it uses. Thus, it can be embedded in any project. He wants a new macro. Eg: DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); becomes DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); I suggested embedding the calling convention in with the DL_IMPORT macro, but he pointed out this macro is also used for variables, where the convention syntax is illegal. To my mind this is reasonable (maybe not the spelling, but definately the intent). Any thoughts? Mark. From mal@lemburg.com Sat Oct 30 09:46:30 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 30 Oct 1999 10:46:30 +0200 Subject: [Python-Dev] Embedding Python when using different calling conventions. References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> Message-ID: <381AB066.B54A47E0@lemburg.com> Mark Hammond wrote: > > This is a bit yucky, but still a valid problem. > > Malte Kroeger [kroeger@bigfoot.com] recently posted to python-help > with a problem. He has an existing Windows project that he wishes to > use Python in. This project does not use the standard __cdecl calling > convention that Python uses, for various reasons known only to him. > As it is an existing project and quite probably a large, complex one, > I am willing to accept that moving his existing project to match > Python's calling convention is not reasonable. I also feel for him, > as I have personally battled this - both with Python and with other > projects. Isn't the default calling scheme selectable via compiler switches ? I remember that this was the case with the IBM compiler on OS/2. > He has requested that Python explicitely declare the calling > convention it uses. Thus, it can be embedded in any project. > > He wants a new macro. Eg: > > DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); > becomes > DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); > > I suggested embedding the calling convention in with the DL_IMPORT > macro, but he pointed out this macro is also used for variables, where > the convention syntax is illegal. Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a better idea. This would leave the previous definition of DL_IMPORT untouched (which is used by a few extensions too). OTOH, we could take chance to reorganize these macros from bottom up: when I started coding extensions I found them not very useful mostly because I didn't have control over them meaning "export this symbol" or "import the symbol". Especially the DL_IMPORT macro is strange because it seems to handle both import *and* export depending on whether Python is compiled or not. FYI, I'm using these macros for the mx extensions: /* Macros to control export and import of DLL symbols. We use our own definitions since Python's don't allow specifying both imported and exported symbols at the same time. */ /* Macro to "mark" a symbol for DLL export */ #if (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_EXPORT(type) extern "C" type __declspec(dllexport) # else # define MX_EXPORT(type) extern type __declspec(dllexport) # endif #elif defined(__WATCOMC__) # define MX_EXPORT(type) extern type __export #else # define MX_EXPORT(type) extern type #endif /* Macro to "mark" a symbol for DLL import */ #if defined(__BORLANDC__) # define MX_IMPORT(type) extern type __import #elif (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_IMPORT(type) extern "C" type __declspec(dllimport) # else # define MX_IMPORT(type) extern type __declspec(dllimport) # endif #else # define MX_IMPORT(type) extern type #endif plus these kind of defines in the extension header files: #ifdef MX_BUILDING_MXDATETIME # define MXDATETIME_EXTERNALIZE MX_EXPORT #else # define MXDATETIME_EXTERNALIZE MX_IMPORT #endif Note that MX_EXPORT always defines export symbols and MX_IMPORT always means "import the symbol". The *_EXTERNALIZE macro decides which form to take depending on whether the header file is used to compile the extension itself or using the extension. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 62 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm@hypernet.com Sun Oct 31 15:59:16 1999 From: gmcm@hypernet.com (Gordon McMillan) Date: Sun, 31 Oct 1999 10:59:16 -0500 Subject: [Python-Dev] dircache.py Message-ID: <1270737688-19939033@hypernet.com> Pursuant to my volunteering to implement Guido's plan to combine cmp.py, cmpcache.py, dircmp.py and dircache.py into filecmp.py, I did some investigating of dircache.py. I find it completely unreliable. On my NT box, the mtime of the directory is updated (on average) 2 secs after a file is added, but within 10 tries, there's always one in which it takes more than 100 secs (and my test script quits). My Linux box hardly ever detects a change within 100 secs. I've tried a number of ways of testing this ("this" being checking for a change in the mtime of the directory), the latest of which is below. Even if dircache can be made to work reliably and surprise-free on some platforms, I doubt it can be done cross-platform. So I'd recommend that it just get dropped. Comments? --------------------------------------------------- import os import sys import time d = os.getcwd() atimes = [] def test(): m = os.stat(d)[8] for i in range(10): fnm = 's%d.tmp' % i open(fnm,'w').write('dummy - delete me') for j in range(10000): newm = os.stat(d)[8] if newm != m: atimes.append(j*0.01) m = newm break time.sleep(0.01) else: print "At round %d, failed to detect add within %3.2f secs" % (i, j*0.01) break def report(): import operator if atimes: print "detect adds: min= %3.2f max= %3.2f avg= %3.2f" % (min(atimes), max(atimes), reduce(operator.add, atimes, 0.0)/len(atimes)) else: print "no successfully detected adds" test() report() - Gordon From mal@lemburg.com Sun Oct 31 23:00:55 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 01 Nov 1999 00:00:55 +0100 Subject: [Python-Dev] Misleading syntax error text References: <1270838575-13870925@hypernet.com> Message-ID: <381CCA27.59506CF6@lemburg.com> [Extracted from the psa-members list...] Gordon McMillan wrote: > > Chris Fama wrote, > > And now the rub: the exact same function definition has passed > > through byte-compilation perfectly OK many times before with no > > problems... of course, this points rather clearly to the > > preceding code, but it illustrates a failing in Python's syntax > > error messages, and IMHO a fairly serious one at that, if this is > > indeed so. > > My simple experiments refuse to compile a "del getattr(..)" at > all. Hmm, it seems to be a failry generic error: >>> del f(x,y) SyntaxError: can't assign to function call How about chainging the com_assign_trailer function in Python/compile.c to: static void com_assign_trailer(c, n, assigning) struct compiling *c; node *n; int assigning; { REQ(n, trailer); switch (TYPE(CHILD(n, 0))) { case LPAR: /* '(' [exprlist] ')' */ com_error(c, PyExc_SyntaxError, assigning ? "can't assign to function call": "can't delete expression"); break; case DOT: /* '.' NAME */ com_assign_attr(c, CHILD(n, 1), assigning); break; case LSQB: /* '[' subscriptlist ']' */ com_subscriptlist(c, CHILD(n, 1), assigning); break; default: com_error(c, PyExc_SystemError, "unknown trailer type"); } } or something along those lines... BTW, has anybody tried my import patch recently ? I haven't heard any citicism since posting it and wonder what made the list fall asleep over the topic :-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 61 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mhammond at skippinet.com.au Fri Oct 1 02:27:03 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 1 Oct 1999 10:27:03 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us> Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat> OK - general agreement. Wheee :-) How about this: def getopt_or_die(opts, long_opts=[], usage=None, prog_name=None, args=None, exit_code = 1): if usage is None, we build a very simple usage string from opts/long_opts. If prog_name is None, we use os.path.basename(sys.argv[0]). This is printed just before the usage message. If args is None, we use sys.argv[1:] exit_code specifies the param to sys.exit() on invalid options. I have based the ordering on my guess at the most likely to be used - but maybe "prog_name" and "args" should be reversed? This should _not_ be all-singing, all-dancing, as it is simple to use the existing getopt.getopt() directly for more esoteric requirements; the old 80-20 rule applies here :-) If the general agreement continues, I will then knock together an implementation. Mark. From gward at cnri.reston.va.us Fri Oct 1 02:51:37 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Thu, 30 Sep 1999 20:51:37 -0400 Subject: [Python-Dev] getopt helper? In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000 References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat> Message-ID: <19990930205136.A14297@cnri.reston.va.us> On 01 October 1999, Mark Hammond said: > OK - general agreement. Wheee :-) > > How about this: > > def getopt_or_die(opts, > long_opts=[], > usage=None, > prog_name=None, > args=None, > exit_code = 1): > > if usage is None, we build a very simple usage string from > opts/long_opts. I still think it would be very desirable to tie the short and long options together. Eg. options = [('verbose', 'v'), ('quiet', 'q'), ('thingy', None), (None, 'x') ('output=', 'o:')] opts, args = getopt_or_die (options, usage, ...) Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x', and 'value' -- never 'v', 'q', or 'o' (Look, I restrained my tendency to invent type systems and auto-generate help text. There may be hope for me yet.) Greg From tim_one at email.msn.com Fri Oct 1 07:55:46 1999 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 1 Oct 1999 01:55:46 -0400 Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr> Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim> [Vladimir Marangozov, plugging] > Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating > Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978. Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, perhaps? it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim From mhammond at skippinet.com.au Sun Oct 3 09:52:59 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 3 Oct 1999 17:52:59 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <19990930205136.A14297@cnri.reston.va.us> Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat> Greg writes: > I still think it would be very desirable to tie the short and long > options together. Eg. > > options = [('verbose', 'v'), > ('quiet', 'q'), > ('thingy', None), > (None, 'x') > ('output=', 'o:')] > opts, args = getopt_or_die (options, usage, ...) > Im not convinced this is worth it. I only use "long options" when I have too many, or a few obscure ones. I have never have "-v" synonymous for "--verbose" - why bother? I know I would never type the later:-) The existing mechanism still handles this quite well - the standard "if opt==blah:" simply becomes "if opt in [...]:" - no real drag. Plus its less change for reasonable reward - handy enough I may actually add command-line handling as I create each little test/util script :-) What say anyone else? Go with my "little change", Gregs "only slightly more change" or "don't worry about it"? Mark. From skip at mojam.com Sun Oct 3 16:26:54 1999 From: skip at mojam.com (Skip Montanaro) Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT) Subject: [Python-Dev] getopt helper? In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat> References: <19990930205136.A14297@cnri.reston.va.us> <001a01bf0d74$5031ed80$0801a8c0@bobcat> Message-ID: <14327.26542.101415.144270@dolphin.mojam.com> Mark> Im not convinced this [pairing up long and short options] is worth Mark> it. The primary reason where it would be helpful is to generate clearer default usage strings. Aside from that, I'm not sure the extra structure would be worth it. Skip From jeremy at cnri.reston.va.us Sun Oct 3 19:05:18 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT) Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim> References: <199909181417.PAA20866@pukapuka.inrialpes.fr> <000101bf0bd1$9b1cf5a0$842d153f@tim> Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us> >>>>> "TP" == Tim Peters writes: TP> [Vladimir Marangozov, plugging] >> Saltzer J., "Naming and Binding of Objects", in Bayer R., >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, >> 1978. TP> Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, TP> perhaps? Indeed he was. TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim I think sixth degrees of separation only made sense in the pre-email world. These days it's probably down to four or five. Jeremy From mhammond at skippinet.com.au Mon Oct 4 01:30:25 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 4 Oct 1999 09:30:25 +1000 Subject: [Python-Dev] ESR on slashdot Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat> Just as a matter of interest, here is a question put to ESR and his answer. We certainly could do alot worse than to have ESR becoming a real Python advocate :-) If only Guido himself could find time to work on 1.6, we would be "in like Flynn" :-) Mark. shawnhargreaves asks: You've always been involved in hacker projects outside of just coding (eg. the Jargon File), but over the last year or so the spokesperson role seems to have grown into a fulltime job. How long is it since you last sat down to write a major piece of software? Do you expect to go back to fulltime development work anytime soon, and if so, what would you work on? How do you manage to cope with the withdrawal symptoms? ESR answers: An astute question ;-). I haven't sat down to write a major piece of software from scratch in months, but I am continuing to maintain fetchmail. I just took over the gif2png beta code with Greg Roelofs's consent; the 1.0.0 version might be out by the time you read this. Today I did some work on gnuplot, bringing the PNG driver up to date. If I get to go full-time again soon, I want to go back to work on Trove, the distributed web-based code-archiving system I designed last year. I'd also like to work with Guido van Rossum on Python 1.6; there are some long-time wishlist features like rich comparisons and a full lambda facility that I care enough about to implement myself. I also have a strategy-gaming system I wrote back in the 1980s that I'd like to put a modern (Web-based) interface on. Finally, having contributed a bit of code to GNOME (the network-monitor applet) I'd like to balance things by doing something for KDE. From gstein at lyra.org Mon Oct 4 11:51:53 1999 From: gstein at lyra.org (Greg Stein) Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT) Subject: [Python-Dev] Alternative Approach to Relative Imports In-Reply-To: <37F21B2F.DD65738F@interet.com> Message-ID: On Wed, 29 Sep 1999, James C. Ahlstrom wrote: > "M.-A. Lemburg" wrote: > > I know, but there still is no way to query what kind of hooks > > are already loaded and what is worse, you cannot unload or reorder > > them. > > I think this is a valid point. I am interested in hooks to read > modules from a file archive. If you are a developer, it is > necessary to turn this hook OFF, so that you can revert to the > usual directory tree where your current source is. > > I am solving this by leaving a global variable "Importer" in > sitecustomize, and calling sitecustomize.Importer.enable(0). > This works, but it might be useful if imputil could de-install > a hook as well as install it. It was a design point to not provide this functionality. It is pretty difficult to unhook the importers from the chain. I specifically said, "well... when you alter the import behavior, then it will stay that way." I figured this was entirely safe since an Importer could have an enable/disable flag like you implemented, or my (theoretical) Import Manager could pull an Importer out of its list that it was managing. I'm not sure that we want an Import Manager to always be installed in the hooks, but it could be a good idea to have a standard manager in the library somewhere (which Importers could state a dependency upon its installation). Cheers, -g -- Greg Stein, http://www.lyra.org/ From jim at interet.com Mon Oct 4 17:16:28 1999 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 04 Oct 1999 11:16:28 -0400 Subject: [Python-Dev] Alternative Approach to Relative Imports References: Message-ID: <37F8C4CC.6C230B06@interet.com> Greg Stein wrote: > It was a design point to not provide this functionality. It is pretty > difficult to unhook the importers from the chain. I specifically said, > "well... when you alter the import behavior, then it will stay that way." > > I figured this was entirely safe since an Importer could have an > enable/disable flag like you implemented, or my (theoretical) Import > Manager could pull an Importer out of its list that it was managing. I think my design of leaving a global "Importer" instance variable in imputil is a bit lame. Each importer is a class instance, but I don't see a list of importers in imputil. Suppose impuil kept a list of installed importers imputil.ImporterList[]. Then to access an importer I have installed, I can write: for im in imputil.ImporterList: if isinstance(im, MyImporter): im.enable(0) It would not be necessary to dis-install an importer, imputil would just undertake to keep a list of installed importers, and if someone wanted to control their installed importers, they would use the list. I do not feel too strongly about this. Maybe it is a good idea. What do you think? I can just use my global variable I guess. Jim Ahlstrom From fredrik at pythonware.com Wed Oct 6 11:52:55 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 6 Oct 1999 11:52:55 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> http://www.cobolscript.com/ "[COBOL's] just a language whose superiority for developing certain types of modern systems has been overlooked until now" PROCEDURE DIVISION. 0000-MAIN. DISPLAY WEB-PAGE-HEADER. ACCEPT DATA FROM WEBPAGE. COMPUTE grand_total = subtotal *(1 sales_tax_rate). DISPLAY WEB-PAGE-BODY. DISPLAY WEB-PAGE-FOOTER. well, why not? :-) From jack at oratrix.nl Wed Oct 6 13:02:39 1999 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 06 Oct 1999 13:02:39 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Message by "Fredrik Lundh" , Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> > http://www.cobolscript.com/ > > "[COBOL's] just a language whose superiority for > developing certain types of modern systems has > been overlooked until now" The whole site sort-of makes me wonder whether this is one big elaborate joke. But if it is somebody put an incredible amount of work in it. The funny thing is that the idea of using Cobol for web-programming _did_ initially strike me as a neat idea: because of the elaborate data descriptions and report generation facilities you could conceivably use all that info to automatically generate all the input forms and such. But they have apparently done no such thing... The timesheet example is, uhm, interesting. 1500 lines of code, with many parameters hardcoded in the source. I'd be surprised if it would take more than 100 lines in Python, with a lot more customizability too. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at CNRI.Reston.VA.US Wed Oct 6 16:57:21 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 10:57:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us> > X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10) > X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET > OVERLEEFD! Ach! Wish I was there! > > http://www.cobolscript.com/ > > > > "[COBOL's] just a language whose superiority for > > developing certain types of modern systems has > > been overlooked until now" > The whole site sort-of makes me wonder whether this is one big > elaborate joke. But if it is somebody put an incredible amount of > work in it. Definitely a joke. Try http://www.cobolscript.com/csfaq.htm#question9 "One of the other advantages of COBOL is that COBOL file processing statements are very simple, with no knowledge of disk head positioning required." But yes, an incredibly good one! Worth filling out the form on the "contact us page" and seeing what they send back. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm at hypernet.com Wed Oct 6 18:55:18 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 6 Oct 1999 12:55:18 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us> References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <1272894334-31005071@hypernet.com> [Guido, on http://www.cobolscript.com/] > Definitely a joke. Try > > http://www.cobolscript.com/csfaq.htm#question9 > > "One of the other advantages of COBOL is that COBOL file > processing statements are very simple, with no knowledge of disk > head positioning required." > > But yes, an incredibly good one! Worth filling out the form on > the "contact us page" and seeing what they send back. While funny, I can virtually guaruntee these people are serious. It is a common misperception among mainframe/COBOL types that C/Unix has *only* character I/O (which does not exist in the former environment at all - even terminals are block I/O). They regard this as a sign of their vast superiority. (And I dearly wish that born-again "Windoze" bashers be sentenced to work in this environment - they'll soon realize how closely related Windows and Unix are). I did a number of stints introducing client / server to Big Blue shops. (Unix made it's entry *only* because RDBMS's ran on them, and all these shops claimed they would dump Unix as soon as these products worked right on big iron). I *always* had an endless fight with the people who wanted to use COBOL instead of C / C++ (on both the Unix boxes and the PCs). MicroFocus distributed a "white paper" comparing COBOL to C that I came to know very, very well. It came in 4 sections: - the Executive Summary said COBOL was vastly superior in all respects - the White Paper said COBOL was more maintainable (translation - you can hire brown-nosing dorks in suits, instead of geeks in T-shirts) and often had superior performance - the Benchmark showed that C smoked COBOL in absolutely everything except binary search (a COBOL builtin) - the Appendix showed that the C code for "binary search" was a very badly coded linear search. But no shop had ever read past the Executive Summary. And don't forget that there is probably more than one order-of- magnitude more COBOL source out there than source in any other (or maybe all other) language(s). All with no built-in date type; and hardly ever using common date routines either (calling external programs in COBOL is expensive, and awkward, because all variables are global). Y2K-compliant-by-omission-ly y'rs - Gordon From guido at CNRI.Reston.VA.US Wed Oct 6 19:00:50 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 13:00:50 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT." <199910061457.KAA08749@eric.cnri.reston.va.us> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> <199910061457.KAA08749@eric.cnri.reston.va.us> Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us> Now I'm confused... I typed in the comment box: Very good joke. ROFL. Where do you guys find the time and energy to do this! :-) and got this back: Mr. van Rossum Glad you took the time out of your busy schedule to berate us. We must be doing something right! ;) Chuck Shereda Deskware, Inc. www.deskware.com www.cobolscript.com --Guido van Rossum (home page: http://www.python.org/~guido/) From klm at digicool.com Wed Oct 6 19:19:30 1999 From: klm at digicool.com (klm) Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT) Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us> Message-ID: On Wed, 6 Oct 1999, Guido van Rossum wrote: > Now I'm confused... I typed in the comment box: > > [...] > and got this back: > > Mr. van Rossum > > Glad you took the time out of your busy schedule to berate us. > We must be doing something right! ;) > > Chuck Shereda > Deskware, Inc. > www.deskware.com > www.cobolscript.com Apparently deskware is a known, bona fide organization. Considering the massive number of cobol programmers around, and despite how cumbersome the prospect is (and with the advantage of factoring in the things gordon said), i guess someone thinks there's leverage in making cobol a scripting language. I think it's not so different than making interpreted versions of C (but i'm not very C friendly). Ken klm at digicool.com From klm at digicool.com Wed Oct 6 20:05:21 1999 From: klm at digicool.com (Ken Manheimer) Date: Wed, 6 Oct 1999 14:05:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com> Concerning the possibility of cobolscript, i wrote: > said), i guess someone thinks there's leverage in making cobol a scripting > language. I think it's not so different than making interpreted versions > of C (but i'm not very C friendly). After posting i thought this might come off as more ignorantly bigoted than i meant for it to seem:-) I was trying to say that C doesn't seem very well suited to scripting/running interpreted, like cobol - not that C is as fraught with ancient and awkward design as cobol (seems). Sigh. Ken klm at digicool.com From mal at lemburg.com Mon Oct 11 22:36:07 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 11 Oct 1999 22:36:07 +0200 Subject: [Python-Dev] Walking up the package hierarchy Message-ID: <38024A37.D92E7091@lemburg.com> Hi everybody, while I'm still thinking about writing the import manager, here is a patch that implements the walk-up-the-hierarchy import scheme that got so much positive feedback. I'm intending to use this implementation as proof of concept for the switch to my new package structure, but wouldn't mind seeing something like it the distribution as well ;-) It changes the default import mechanism to work like this: >>> import d try a.b.c.d try a.b.d try a.d try d fail instead of just doing the current two-level lookup: >>> import d try a.b.c.d try d fail As a result, relative imports referring to higher level packages work out of the box without any ugly underscores in the import name. Plus the whole scheme is pretty simple to explain and straightforward. Since the patch is so small, I attached it to this mail. Hope you don't mind. The ZIP archive also contains a sample package which demonstrates the feature. Run Python with -v flag to see how the new scheme works. Feedback is most welcome. I am especially interested whether the scheme breaks any existing packages. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 81 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: walkingimport.zip Type: application/x-zip-compressed Size: 2669 bytes Desc: not available URL: From bwarsaw at cnri.reston.va.us Tue Oct 12 22:21:02 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT) Subject: [Python-Dev] string methods branch Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us> Guido has agreed to let me mainline the string methods branch. Those of you on python-checkins should have seen the CVS messages by now. This is a good thing because I think we can all agree we hate CVS branches. For me, that final merge put the nail in the coffin. Anyway, those of you who have put off playing with string methods until now should just be able to do a CVS update, rebuild, and go. You should read the revision log messages for the branch checkins for details of the changes. Let me know if you have any problems. Fred and I will work out changes to the documentation some time soon. >>> sig=['branches','are','only','useful','for','trees','and','streams','ly'] >>> print '-'.join(sig) + " y'rs" -Barry From skip at mojam.com Tue Oct 12 23:03:13 1999 From: skip at mojam.com (Skip Montanaro) Date: Tue, 12 Oct 1999 16:03:13 -0500 Subject: [Python-Dev] new opportunities for obfuscation... ;-) Message-ID: <199910122103.QAA31864@dolphin.mojam.com> Barry's note prompted me to update my Python tree. The result: >>> ".".join(dir("")) 'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper' A job well done, Barry... Skip Montanaro | http://www.mojam.com/ skip at mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... From mal at lemburg.com Wed Oct 13 14:27:57 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 13 Oct 1999 14:27:57 +0200 Subject: [Python-Dev] Walking up the package hierarchy References: <38024A37.D92E7091@lemburg.com> Message-ID: <38047ACD.E716154E@lemburg.com> Strange... I would have thought that this new patch would stir up some cheers or opposition. Has anyone tried it in some real apps ? It would be interesting to see whether it breaks any code in e.g. packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't break anything for my packages or apps. > It changes the default import mechanism to work like this: > > >>> import d > try a.b.c.d > try a.b.d > try a.d > try d > fail > > instead of just doing the current two-level lookup: > > >>> import d > try a.b.c.d > try d > fail -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 79 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Thu Oct 14 13:26:11 1999 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT) Subject: [Python-Dev] Walking up the package hierarchy In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm" Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr> M.-A. Lemburg wrote: > > Strange... I would have thought that this new patch would stir up > some cheers or opposition. Has anyone tried it in some real apps ? Not yet, but this looks better as a default search path. > > It would be interesting to see whether it breaks any code in e.g. > packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't > break anything for my packages or apps. JimF, /F, Guido and other package maintainers could do you a favor by trying your patch ;-) and give us some real feedback on this. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Fri Oct 15 09:21:15 1999 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 15 Oct 1999 03:21:15 -0400 Subject: [Python-Dev] Corporate installations Message-ID: <000401bf16dd$def75d80$d72d153f@tim> Python is getting used widely enough in my place of employment that people are agitating for a common installation (personal variants are screwing people too often). Various machines are running Win95, Win98, NT, Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke on that whole banana when it's shoved down my throat. For starters, I just need to get it running across Windows platforms. Never looked into this before, and it seems to be exceedingly complicated right out of the box <0.5 wink>: D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON'] >>> Where does all that stuff come from? The first is apparently the current directory; cool. The next 4 appear to come from MarkH's stuff, via the registry. The next 4 appear to come from Python's own registry PythonPath key. The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows -- case differences). The last is another mystery. site.py isn't implicated in any of them (same thing when running with -S). I suppose this is a clue: D:\Python>set PYTHONHOME=ick;fooey D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> sys.path ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'ick', 'fooey\\DLLs', 'ick', 'fooey\\lib', 'ick', 'fooey\\lib\\plat-win', 'ick', 'fooey\\lib\\lib-tk', 'D:\\PYTHON'] >>> Doesn't appear to be sensible, but at least it's predictable . I was surprised to find that setting PYTHONPATH can't be used to override any of this -- it just inserts even more stuff, into sys.path[1:1]. Do I really care? Not much -- the complexity just makes it hard to get a mental model of what Python *thinks* it's trying to accomplish here, and so harder to figure out what needs to be done. Which is pretty severe: "Dragon std" apps must run the same version of Python (which can be local) with the same libraries (which must be network-mounted), regardless of whatever version of Python each user may have built on their own, and regardless of their registry settings or envar values. I think this means I need to distribute a python15.dll and python.exe (via our source control system) into a directory very early on the PATH (other common .exe's are distributed this way, so no big deal), and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the common Dragon dir. Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK. There's no way to do that from within Python, is there? If not, everyone going through "unfortunate" paths in the network will have to set that themselves. Anyone have better ideas? That shouldn't be hard . the-difference-between-one-user-and-two-is-infinite-ly y'rs - tim From mhammond at skippinet.com.au Fri Oct 15 10:02:14 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 15 Oct 1999 18:02:14 +1000 Subject: [Python-Dev] Corporate installations In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat> > The 4 after that are a mystery, and duplicate the > preceding 4 (except > for meaningless-- it's Windows -- case differences). Python makes a brave attempt to deduce the PYTHONHOME itself by looking for "well-known" files in the lib directory. Python15.dll uses argv[0] or the result of GetModuleFileName(NULL) (whichever is deemed "better" by the existance of a slash) as the basis for a search for the landmark file. If found, those 4 entries are added and if not they are added relatively (ie ".\lib" in the vain hope they will suddenly become meaningful (which they almost certainly wont) So, when running a .EXE that lives in the main Python directory (such as Python.exe), we get duplicated entries - the ones we deduced, and the ones explicitely in the registry. The problem arises when Python15.dll is used by a .exe that doesnt live in this nice directory - eg Pythonwin, or any other embedding, such as COM objects or peoples custom apps. As argv[0] and GetModuleFileName(NULL) both return a directory where "\lib" appended will not find the landmark file (string.py for windows), you get the useless relative paths added. So, what this means is that Python's strategy for deducing the PythonPath only works for Python.exe and Pythonw.exe - typically the only .exes in the Python directory. So we have the situation where the paths must also be registered in the registry if any other .exe wants to work. > I was surprised to find that setting PYTHONPATH can't be used > to override > any of this -- it just inserts even more stuff, into sys.path[1:1]. Once upon a time Guido stated that PYTHONPATH should override the registry completely. I cant recall the history of this tho, and wouldnt object is that was the case. You are then faced with how to set this env variable (and if you are doing that, why not just set the registry?) > I think this means I need to distribute a python15.dll and > python.exe (via > our source control system) into a directory very early on the > PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC > paths, + the > common Dragon dir. This should be fine - as long as no one needs to run any other .EXE that needs Python15.dll (or unless that other .exe is also in that same directory). > Network name mangling being what it is, I suppose I'll also > need to force > PYTHONCASEOK. There's no way to do that from within Python, > is there? If While my views on this have temepered from illogically ranting to Guido how much I hate it, I still believe this is a mis-feature for Windows. The other alternative is to put Python.exe on the network path, and have your library in a ".\lib" directory under that. Doesnt really solve the problem for your "DragonLib" stuff - Im sure you dont want to stuff _everything_ into a single .lib directory. Also, IMO Python shouldnt bother going sniffing for its library if the registry exists. It just adds time to startup, and if it works is almost guaranteed to be redundant, and if it doesnt work will add useless entries that slow down module searches. However, that still doesnt solve your problem. The final suggestion is to put some of the win32 extensions (specifically, win32api) on a network share along with Python.exe and the standard lib. Then provide a .bat file that actually sets up the registry, and off you go. Sure, people hate the registry, but setting an environment variable is worse. Or an alternative - provide a .reg file with the necessary registry keys - users can "execute" it (double-clicking from explorer, typing the name in start->run, execute "start whatever.reg in their logon script, etc) to have their registry setup. I wish I had a better answer, but can't for the life of me work out what it should be even if MS supported it! Mark. From mal at lemburg.com Fri Oct 15 10:34:14 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 15 Oct 1999 10:34:14 +0200 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <3806E706.82FEB673@lemburg.com> Tim Peters wrote: > > Python is getting used widely enough in my place of employment that people > are agitating for a common installation (personal variants are screwing > people too often). Various machines are running Win95, Win98, NT, > Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke > on that whole banana when it's shoved down my throat. > > For starters, I just need to get it running across Windows platforms. Never > looked into this before, and it seems to be exceedingly complicated right > out of the box <0.5 wink>: > > D:\Python>python > Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import sys > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? The first is apparently the current > directory; cool. The next 4 appear to come from MarkH's stuff, via the > registry. The next 4 appear to come from Python's own registry PythonPath > key. The 4 after that are a mystery, and duplicate the preceding 4 (except > for meaningless-- it's Windows -- case differences). The last is > another mystery. site.py isn't implicated in any of them (same thing when > running with -S). On Linux I get: ['', '/home/lemburg/bin', '/home/lemburg/lib', '/home/lemburg/projects', '/home/lemburg/python/Lib/', '/home/lemburg/python/Lib/test', '/home/lemburg/python/Lib/plat-linux2', '/home/lemburg/python/Lib/lib-tk', '/home/lemburg/python/Modules', '/usr/local/lib/python1.5/site-packages'] It seems that the last entry refers to what Python thinks is the standard location for system wide extensions. The first 3 come from my PYTHONPATH setting, the next few are inserted by the Python startup code based on what Python found as landmark to determine PYTHONHOME. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the > common Dragon dir. Sounds reasonable ;-) > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. There's no way to do that from within Python, is there? If > not, everyone going through "unfortunate" paths in the network will have to > set that themselves. If Windows allows writing the process' environment you can set PYTHONCASEOK dynamically: the check queries the environment for the flag prior to every check (instead of doing going the usual internal Python flag way as many of the others do). See Python/import.c:check_case() for details. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 77 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Fri Oct 15 17:22:38 1999 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 11:22:38 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <380746BE.FAE46A0A@interet.com> Tim Peters wrote: > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? Good question. I don't know, and every time I start to think I do, I am wrong. Certainly PYTHONPATH is full of junk on Windows. The point is that PYTHONPATH just doesn't work for commercial installations. Please see these for some discussion: ftp://ftp.interet.com/bootmodule.html ftp://ftp.interet.com/pylib.html I think the solution is to put the library files and packages into archive files (in some format yet to be determined) and find them by looking in the directory of python15.dll and/or python.exe. On Unix there is $prefix, which actually seems to work. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH Yes, that is a good start. Just understand that *.pyd and and DLL's which are imported (instead of linked against) are found from PYTHONPATH, not PATH. Also you will need a valid PATH on all PC's which is quite a bother. An alternative is to use the Wise installer to set up icons for your apps. Real Windows apps don't use PATH. We use Wise for internal as well as external apps. Note that if you import a module "import foo", and foo lives in "foo.dll", then on Windows, PYTHONPATH is searched, and the standard Windows DLL path is not searched. That means you can't use standard Windows locations for DLL's which are dynamically imported. This is an error and should be fixed. > and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) The problem is that you already need a valid PYTHONPATH to find sitecustomize.py. Better is to create a custom python15.dll with sitecustomize.py, exceptions.py and site.py (all needed during boot) frozen in as frozen modules. In our office I freeze in other library files too. > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. I don't seem to need that on 95/98/NT. Network names shouldn't get mangled on these systems. I guess you mean lack of case sensitivity, but just make sure the case is correct in the Lib directory. This is another reason to prefer archive files anyway. But no, you shouldn't need PYTHONCASEOK. > Anyone have better ideas? That shouldn't be hard . Yes, this is a major problem with Python's acceptance for commercial apps (and I include internal production code as an app) so lets figure out what to do and fix it. Jim Ahlstrom From jim at interet.com Fri Oct 15 20:19:41 1999 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 14:19:41 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> Message-ID: <3807703D.9FD09C5B@interet.com> "James C. Ahlstrom" wrote: Sorry, correct URL is: ftp://ftp.interet.com/pub/bootmodule.html ftp://ftp.interet.com/pub/pylib.htm Jim Ahlstrom From fredrik at pythonware.com Fri Oct 15 21:17:05 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:17:05 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> while doing the final checks for my upcoming standard library guide, I thought I'd check what had changed in the CVS version. some old (1.5.1) junk was still to be found in the lib-old subdirectory, but certain 1.5.2 things seem to have vanished into thin air. like find.py, for example. does anyone know where it is? after all, it's kinda useful, and I just pointed someone to it, only to find that he didn't have it on his machine... is there an official list of totally deprecated modules somewhere? From fdrake at acm.org Fri Oct 15 21:44:29 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 15 Oct 1999 15:44:29 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us> Fredrik Lundh writes: > some old (1.5.1) junk was still to be found in the > lib-old subdirectory, but certain 1.5.2 things seem > to have vanished into thin air. > > like find.py, for example. does anyone know > where it is? after all, it's kinda useful, and I It should be in lib-old. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fredrik at pythonware.com Fri Oct 15 21:58:17 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:58:17 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Fred L. Drake, Jr. wrote: > > like find.py, for example. does anyone know > > where it is? after all, it's kinda useful, and I > > It should be in lib-old. "should" as in "is already there" or "oops, I'll fix it" ? :-) [fredrik at brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/ CVS codehack.py newdir.py rand.py whatsound.py Para.py fmt.py ni.py tb.py zmod.py addpack.py lockfile.py poly.py util.py (sure looks like "oops" to me...) From fdrake at acm.org Fri Oct 15 22:41:14 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 15 Oct 1999 16:41:14 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us> Fredrik Lundh writes: > "should" as in "is already there" or > "oops, I'll fix it" ? :-) It's certainly in lib-old/ in the CVS repository. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tismer at appliedbiometrics.com Fri Oct 15 23:55:36 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 15 Oct 1999 23:55:36 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com> "Fred L. Drake, Jr." wrote: > > Fredrik Lundh writes: > > "should" as in "is already there" or > > "oops, I'll fix it" ? :-) > > It's certainly in lib-old/ in the CVS repository. Sorry. Definately certainly not. But a find.py is in Demo/threads. Fred (any of both :) did you mean that? ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From fredrik at pythonware.com Mon Oct 18 09:31:16 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 18 Oct 1999 09:31:16 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> > > > "should" as in "is already there" or > > > "oops, I'll fix it" ? :-) > > > > It's certainly in lib-old/ in the CVS repository. > > Sorry. Definately certainly not. > > But a find.py is in Demo/threads. > Fred (any of both :) did you mean that? I cannot see any "find.py" in either Lib (where it is in all my copies of 1.5.2) or Lib/lib-old. fwiw, I can think of a few dozen other standard library modules that I'd remove before this one. cannot we put it back? please? :-) (after all, it's been a reoccuring theme on comp.lang.python lately. and 1.5.2+ breaks my new book...). From fdrake at acm.org Mon Oct 18 16:31:34 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 18 Oct 1999 10:31:34 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us> Fredrik Lundh writes: > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It most certainly *should* be appearing in lib-old; I just checked the internal CVS repository and it's really there. Perhaps the anonymous mirror isn't right? (Barry, can you check this? I don't even know where it is, much less whether I can see those directories.) > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) That's up to Guido, not me. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From guido at CNRI.Reston.VA.US Mon Oct 18 16:56:55 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 18 Oct 1999 10:56:55 -0400 Subject: [Python-Dev] what happened to find.py? In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200." <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us> > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, we'll ask Barry to investigate. Maybe the branching messed things up? > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) It's better (and more illustrative) to use os.walk() to do this thing. > (after all, it's been a reoccuring theme on > comp.lang.python lately. and 1.5.2+ breaks > my new book...). Good thing it isn't printed yet. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at cnri.reston.va.us Mon Oct 18 17:35:04 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> <199910181456.KAA22936@eric.cnri.reston.va.us> Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, Guido> we'll ask Barry to investigate. Maybe the branching messed Guido> things up? Somehow the mirror was out of date. Perhaps the branch merge got it out of whack, but in any case, I've done a top-level resync. find.py is definitely in the repository under lib-old now! Hope that helps, -Barry From bwarsaw at cnri.reston.va.us Tue Oct 19 17:30:01 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT) Subject: [Python-Dev] forwarded message from Greg Rose Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Folks, I'm resending this message here for Greg Rose. If anybody can help him out, please respond to ggr at qualcomm.com (not to me). Greg, if you still get no response, then I suggest sending the mssage to greater python-list at python.org. There's gotta be /somebody/ out there who is interested in participating. -Barry ------- start of forwarded message (RFC 934 encapsulation) ------- From: Greg Rose To: bwarsaw at python.org Subject: Re: python advocate in Perl/Python/Tcl bakeoff Date: Tue, 19 Oct 1999 20:28:37 +1000 X-Sender: ggr2 at avalon.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 17:07 30/09/1999 -0400, you wrote: >Hope that helps. If neither of these guys can do it, and can't >suggest someone who can, let me know and we'll post an announcement on >all the usual Python haunts. Well, as they say, those who volunteer end up doing things... I've tried both of your associates, and about three or four others who were recommended, and have struck out. I'd really appreciate your help trying to find someone competent to do this. Bear in mind that the audience is sysadmins, not generic programmers. thanks in advance, Greg. Here's the text I've been sending out, but you should feel free to modify non-factual stuff: Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX conference somewhere or other. It was fun for all involved, and was very well received. We're looking to do something similar at the LISA conference in Seattle. You have been recommended as Python advocate. It would be on thursday 11th november. The idea would be to have a moderator and three advocates, and a slightly rowdy audience. We'd ask each advocate to nominate in advance some simple sysadmin task which shows their language to its advantage, and also to do the solutions to the other two's tasks... then there'd be some room for (presubmitted) tasks from the audience to be solved on the fly. Any suggestions you have regarding how to make it work would be appreciated. Are you intending to attend LISA? Would you be willing to do this? (We have Tom Christiansen for perl and Brent Welch for Tcl/Tk.) Greg Rose INTERNET: ggr at Qualcomm.com Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C ------- end ------- From guido at CNRI.Reston.VA.US Tue Oct 19 17:49:10 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 19 Oct 1999 11:49:10 -0400 Subject: [Python-Dev] forwarded message from Greg Rose In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT." <14348.36473.112615.887932@anthem.cnri.reston.va.us> References: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us> Alas, I'll be at SD99 East in DC that week, teaching Python CGI programming. See http://www.python.org/Events.html --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Tue Oct 19 18:58:34 1999 From: da at ski.org (David Ascher) Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Irrelevant but very informative piece of patent law Message-ID: http://slashdot.org/features/99/10/19/1032254.shtml Very well written, too. Many many standard deviations away from standard slashdot fare. --da From mhammond at skippinet.com.au Sat Oct 30 01:11:54 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 30 Oct 1999 09:11:54 +1000 Subject: [Python-Dev] Embedding Python when using different calling conventions. Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> This is a bit yucky, but still a valid problem. Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help with a problem. He has an existing Windows project that he wishes to use Python in. This project does not use the standard __cdecl calling convention that Python uses, for various reasons known only to him. As it is an existing project and quite probably a large, complex one, I am willing to accept that moving his existing project to match Python's calling convention is not reasonable. I also feel for him, as I have personally battled this - both with Python and with other projects. He has requested that Python explicitely declare the calling convention it uses. Thus, it can be embedded in any project. He wants a new macro. Eg: DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); becomes DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); I suggested embedding the calling convention in with the DL_IMPORT macro, but he pointed out this macro is also used for variables, where the convention syntax is illegal. To my mind this is reasonable (maybe not the spelling, but definately the intent). Any thoughts? Mark. From mal at lemburg.com Sat Oct 30 10:46:30 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 30 Oct 1999 10:46:30 +0200 Subject: [Python-Dev] Embedding Python when using different calling conventions. References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> Message-ID: <381AB066.B54A47E0@lemburg.com> Mark Hammond wrote: > > This is a bit yucky, but still a valid problem. > > Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help > with a problem. He has an existing Windows project that he wishes to > use Python in. This project does not use the standard __cdecl calling > convention that Python uses, for various reasons known only to him. > As it is an existing project and quite probably a large, complex one, > I am willing to accept that moving his existing project to match > Python's calling convention is not reasonable. I also feel for him, > as I have personally battled this - both with Python and with other > projects. Isn't the default calling scheme selectable via compiler switches ? I remember that this was the case with the IBM compiler on OS/2. > He has requested that Python explicitely declare the calling > convention it uses. Thus, it can be embedded in any project. > > He wants a new macro. Eg: > > DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); > becomes > DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); > > I suggested embedding the calling convention in with the DL_IMPORT > macro, but he pointed out this macro is also used for variables, where > the convention syntax is illegal. Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a better idea. This would leave the previous definition of DL_IMPORT untouched (which is used by a few extensions too). OTOH, we could take chance to reorganize these macros from bottom up: when I started coding extensions I found them not very useful mostly because I didn't have control over them meaning "export this symbol" or "import the symbol". Especially the DL_IMPORT macro is strange because it seems to handle both import *and* export depending on whether Python is compiled or not. FYI, I'm using these macros for the mx extensions: /* Macros to control export and import of DLL symbols. We use our own definitions since Python's don't allow specifying both imported and exported symbols at the same time. */ /* Macro to "mark" a symbol for DLL export */ #if (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_EXPORT(type) extern "C" type __declspec(dllexport) # else # define MX_EXPORT(type) extern type __declspec(dllexport) # endif #elif defined(__WATCOMC__) # define MX_EXPORT(type) extern type __export #else # define MX_EXPORT(type) extern type #endif /* Macro to "mark" a symbol for DLL import */ #if defined(__BORLANDC__) # define MX_IMPORT(type) extern type __import #elif (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_IMPORT(type) extern "C" type __declspec(dllimport) # else # define MX_IMPORT(type) extern type __declspec(dllimport) # endif #else # define MX_IMPORT(type) extern type #endif plus these kind of defines in the extension header files: #ifdef MX_BUILDING_MXDATETIME # define MXDATETIME_EXTERNALIZE MX_EXPORT #else # define MXDATETIME_EXTERNALIZE MX_IMPORT #endif Note that MX_EXPORT always defines export symbols and MX_IMPORT always means "import the symbol". The *_EXTERNALIZE macro decides which form to take depending on whether the header file is used to compile the extension itself or using the extension. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 62 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm at hypernet.com Sun Oct 31 16:59:16 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 31 Oct 1999 10:59:16 -0500 Subject: [Python-Dev] dircache.py Message-ID: <1270737688-19939033@hypernet.com> Pursuant to my volunteering to implement Guido's plan to combine cmp.py, cmpcache.py, dircmp.py and dircache.py into filecmp.py, I did some investigating of dircache.py. I find it completely unreliable. On my NT box, the mtime of the directory is updated (on average) 2 secs after a file is added, but within 10 tries, there's always one in which it takes more than 100 secs (and my test script quits). My Linux box hardly ever detects a change within 100 secs. I've tried a number of ways of testing this ("this" being checking for a change in the mtime of the directory), the latest of which is below. Even if dircache can be made to work reliably and surprise-free on some platforms, I doubt it can be done cross-platform. So I'd recommend that it just get dropped. Comments? --------------------------------------------------- import os import sys import time d = os.getcwd() atimes = [] def test(): m = os.stat(d)[8] for i in range(10): fnm = 's%d.tmp' % i open(fnm,'w').write('dummy - delete me') for j in range(10000): newm = os.stat(d)[8] if newm != m: atimes.append(j*0.01) m = newm break time.sleep(0.01) else: print "At round %d, failed to detect add within %3.2f secs" % (i, j*0.01) break def report(): import operator if atimes: print "detect adds: min= %3.2f max= %3.2f avg= %3.2f" % (min(atimes), max(atimes), reduce(operator.add, atimes, 0.0)/len(atimes)) else: print "no successfully detected adds" test() report() - Gordon From mhammond at skippinet.com.au Fri Oct 1 02:27:03 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 1 Oct 1999 10:27:03 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <14323.51267.54862.538939@anthem.cnri.reston.va.us> Message-ID: <001601bf0ba3$b06ad770$0801a8c0@bobcat> OK - general agreement. Wheee :-) How about this: def getopt_or_die(opts, long_opts=[], usage=None, prog_name=None, args=None, exit_code = 1): if usage is None, we build a very simple usage string from opts/long_opts. If prog_name is None, we use os.path.basename(sys.argv[0]). This is printed just before the usage message. If args is None, we use sys.argv[1:] exit_code specifies the param to sys.exit() on invalid options. I have based the ordering on my guess at the most likely to be used - but maybe "prog_name" and "args" should be reversed? This should _not_ be all-singing, all-dancing, as it is simple to use the existing getopt.getopt() directly for more esoteric requirements; the old 80-20 rule applies here :-) If the general agreement continues, I will then knock together an implementation. Mark. From gward at cnri.reston.va.us Fri Oct 1 02:51:37 1999 From: gward at cnri.reston.va.us (Greg Ward) Date: Thu, 30 Sep 1999 20:51:37 -0400 Subject: [Python-Dev] getopt helper? In-Reply-To: <001601bf0ba3$b06ad770$0801a8c0@bobcat>; from Mark Hammond on Fri, Oct 01, 1999 at 10:27:03AM +1000 References: <14323.51267.54862.538939@anthem.cnri.reston.va.us> <001601bf0ba3$b06ad770$0801a8c0@bobcat> Message-ID: <19990930205136.A14297@cnri.reston.va.us> On 01 October 1999, Mark Hammond said: > OK - general agreement. Wheee :-) > > How about this: > > def getopt_or_die(opts, > long_opts=[], > usage=None, > prog_name=None, > args=None, > exit_code = 1): > > if usage is None, we build a very simple usage string from > opts/long_opts. I still think it would be very desirable to tie the short and long options together. Eg. options = [('verbose', 'v'), ('quiet', 'q'), ('thingy', None), (None, 'x') ('output=', 'o:')] opts, args = getopt_or_die (options, usage, ...) Then opts would have possible keys 'verbose', 'quiet', 'thingy', 'x', and 'value' -- never 'v', 'q', or 'o' (Look, I restrained my tendency to invent type systems and auto-generate help text. There may be hope for me yet.) Greg From tim_one at email.msn.com Fri Oct 1 07:55:46 1999 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 1 Oct 1999 01:55:46 -0400 Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <199909181417.PAA20866@pukapuka.inrialpes.fr> Message-ID: <000101bf0bd1$9b1cf5a0$842d153f@tim> [Vladimir Marangozov, plugging] > Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating > Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978. Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, perhaps? it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim From mhammond at skippinet.com.au Sun Oct 3 09:52:59 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sun, 3 Oct 1999 17:52:59 +1000 Subject: [Python-Dev] getopt helper? In-Reply-To: <19990930205136.A14297@cnri.reston.va.us> Message-ID: <001a01bf0d74$5031ed80$0801a8c0@bobcat> Greg writes: > I still think it would be very desirable to tie the short and long > options together. Eg. > > options = [('verbose', 'v'), > ('quiet', 'q'), > ('thingy', None), > (None, 'x') > ('output=', 'o:')] > opts, args = getopt_or_die (options, usage, ...) > Im not convinced this is worth it. I only use "long options" when I have too many, or a few obscure ones. I have never have "-v" synonymous for "--verbose" - why bother? I know I would never type the later:-) The existing mechanism still handles this quite well - the standard "if opt==blah:" simply becomes "if opt in [...]:" - no real drag. Plus its less change for reasonable reward - handy enough I may actually add command-line handling as I create each little test/util script :-) What say anyone else? Go with my "little change", Gregs "only slightly more change" or "don't worry about it"? Mark. From skip at mojam.com Sun Oct 3 16:26:54 1999 From: skip at mojam.com (Skip Montanaro) Date: Sun, 3 Oct 1999 09:26:54 -0500 (CDT) Subject: [Python-Dev] getopt helper? In-Reply-To: <001a01bf0d74$5031ed80$0801a8c0@bobcat> References: <19990930205136.A14297@cnri.reston.va.us> <001a01bf0d74$5031ed80$0801a8c0@bobcat> Message-ID: <14327.26542.101415.144270@dolphin.mojam.com> Mark> Im not convinced this [pairing up long and short options] is worth Mark> it. The primary reason where it would be helpful is to generate clearer default usage strings. Aside from that, I'm not sure the extra structure would be worth it. Skip From jeremy at cnri.reston.va.us Sun Oct 3 19:05:18 1999 From: jeremy at cnri.reston.va.us (Jeremy Hylton) Date: Sun, 3 Oct 1999 13:05:18 -0400 (EDT) Subject: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) In-Reply-To: <000101bf0bd1$9b1cf5a0$842d153f@tim> References: <199909181417.PAA20866@pukapuka.inrialpes.fr> <000101bf0bd1$9b1cf5a0$842d153f@tim> Message-ID: <14327.36046.4763.670777@bitdiddle.cnri.reston.va.us> >>>>> "TP" == Tim Peters writes: TP> [Vladimir Marangozov, plugging] >> Saltzer J., "Naming and Binding of Objects", in Bayer R., >> "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, >> 1978. TP> Wasn't Saltzer one of the CNRI fellows' advisors? Jeremy's, TP> perhaps? Indeed he was. TP> it's-a-small-world-but-even-smaller-than-we-feared-ly y'rs - tim I think sixth degrees of separation only made sense in the pre-email world. These days it's probably down to four or five. Jeremy From mhammond at skippinet.com.au Mon Oct 4 01:30:25 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Mon, 4 Oct 1999 09:30:25 +1000 Subject: [Python-Dev] ESR on slashdot Message-ID: <002001bf0df7$45e964b0$0801a8c0@bobcat> Just as a matter of interest, here is a question put to ESR and his answer. We certainly could do alot worse than to have ESR becoming a real Python advocate :-) If only Guido himself could find time to work on 1.6, we would be "in like Flynn" :-) Mark. shawnhargreaves asks: You've always been involved in hacker projects outside of just coding (eg. the Jargon File), but over the last year or so the spokesperson role seems to have grown into a fulltime job. How long is it since you last sat down to write a major piece of software? Do you expect to go back to fulltime development work anytime soon, and if so, what would you work on? How do you manage to cope with the withdrawal symptoms? ESR answers: An astute question ;-). I haven't sat down to write a major piece of software from scratch in months, but I am continuing to maintain fetchmail. I just took over the gif2png beta code with Greg Roelofs's consent; the 1.0.0 version might be out by the time you read this. Today I did some work on gnuplot, bringing the PNG driver up to date. If I get to go full-time again soon, I want to go back to work on Trove, the distributed web-based code-archiving system I designed last year. I'd also like to work with Guido van Rossum on Python 1.6; there are some long-time wishlist features like rich comparisons and a full lambda facility that I care enough about to implement myself. I also have a strategy-gaming system I wrote back in the 1980s that I'd like to put a modern (Web-based) interface on. Finally, having contributed a bit of code to GNOME (the network-monitor applet) I'd like to balance things by doing something for KDE. From gstein at lyra.org Mon Oct 4 11:51:53 1999 From: gstein at lyra.org (Greg Stein) Date: Mon, 4 Oct 1999 02:51:53 -0700 (PDT) Subject: [Python-Dev] Alternative Approach to Relative Imports In-Reply-To: <37F21B2F.DD65738F@interet.com> Message-ID: On Wed, 29 Sep 1999, James C. Ahlstrom wrote: > "M.-A. Lemburg" wrote: > > I know, but there still is no way to query what kind of hooks > > are already loaded and what is worse, you cannot unload or reorder > > them. > > I think this is a valid point. I am interested in hooks to read > modules from a file archive. If you are a developer, it is > necessary to turn this hook OFF, so that you can revert to the > usual directory tree where your current source is. > > I am solving this by leaving a global variable "Importer" in > sitecustomize, and calling sitecustomize.Importer.enable(0). > This works, but it might be useful if imputil could de-install > a hook as well as install it. It was a design point to not provide this functionality. It is pretty difficult to unhook the importers from the chain. I specifically said, "well... when you alter the import behavior, then it will stay that way." I figured this was entirely safe since an Importer could have an enable/disable flag like you implemented, or my (theoretical) Import Manager could pull an Importer out of its list that it was managing. I'm not sure that we want an Import Manager to always be installed in the hooks, but it could be a good idea to have a standard manager in the library somewhere (which Importers could state a dependency upon its installation). Cheers, -g -- Greg Stein, http://www.lyra.org/ From jim at interet.com Mon Oct 4 17:16:28 1999 From: jim at interet.com (James C. Ahlstrom) Date: Mon, 04 Oct 1999 11:16:28 -0400 Subject: [Python-Dev] Alternative Approach to Relative Imports References: Message-ID: <37F8C4CC.6C230B06@interet.com> Greg Stein wrote: > It was a design point to not provide this functionality. It is pretty > difficult to unhook the importers from the chain. I specifically said, > "well... when you alter the import behavior, then it will stay that way." > > I figured this was entirely safe since an Importer could have an > enable/disable flag like you implemented, or my (theoretical) Import > Manager could pull an Importer out of its list that it was managing. I think my design of leaving a global "Importer" instance variable in imputil is a bit lame. Each importer is a class instance, but I don't see a list of importers in imputil. Suppose impuil kept a list of installed importers imputil.ImporterList[]. Then to access an importer I have installed, I can write: for im in imputil.ImporterList: if isinstance(im, MyImporter): im.enable(0) It would not be necessary to dis-install an importer, imputil would just undertake to keep a list of installed importers, and if someone wanted to control their installed importers, they would use the list. I do not feel too strongly about this. Maybe it is a good idea. What do you think? I can just use my global variable I guess. Jim Ahlstrom From fredrik at pythonware.com Wed Oct 6 11:52:55 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 6 Oct 1999 11:52:55 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> http://www.cobolscript.com/ "[COBOL's] just a language whose superiority for developing certain types of modern systems has been overlooked until now" PROCEDURE DIVISION. 0000-MAIN. DISPLAY WEB-PAGE-HEADER. ACCEPT DATA FROM WEBPAGE. COMPUTE grand_total = subtotal *(1 sales_tax_rate). DISPLAY WEB-PAGE-BODY. DISPLAY WEB-PAGE-FOOTER. well, why not? :-) From jack at oratrix.nl Wed Oct 6 13:02:39 1999 From: jack at oratrix.nl (Jack Jansen) Date: Wed, 06 Oct 1999 13:02:39 +0200 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Message by "Fredrik Lundh" , Wed, 6 Oct 1999 11:52:55 +0200 , <004c01bf0fe0$91534e30$f29b12c2@secret.pythonware.com> Message-ID: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> > http://www.cobolscript.com/ > > "[COBOL's] just a language whose superiority for > developing certain types of modern systems has > been overlooked until now" The whole site sort-of makes me wonder whether this is one big elaborate joke. But if it is somebody put an incredible amount of work in it. The funny thing is that the idea of using Cobol for web-programming _did_ initially strike me as a neat idea: because of the elaborate data descriptions and report generation facilities you could conceivably use all that info to automatically generate all the input forms and such. But they have apparently done no such thing... The timesheet example is, uhm, interesting. 1500 lines of code, with many parameters hardcoded in the source. I'd be surprised if it would take more than 100 lines in Python, with a lot more customizability too. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen at oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido at CNRI.Reston.VA.US Wed Oct 6 16:57:21 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 10:57:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <199910061457.KAA08749@eric.cnri.reston.va.us> > X-Last-Band-Seen: Raggende Mannen afscheidsconcert (Paradiso, 4-10) > X-Mini-Review: IK HEB HET OVERLEEFD! IK HEB HET OVERLEEFD! IK HEB HET > OVERLEEFD! Ach! Wish I was there! > > http://www.cobolscript.com/ > > > > "[COBOL's] just a language whose superiority for > > developing certain types of modern systems has > > been overlooked until now" > The whole site sort-of makes me wonder whether this is one big > elaborate joke. But if it is somebody put an incredible amount of > work in it. Definitely a joke. Try http://www.cobolscript.com/csfaq.htm#question9 "One of the other advantages of COBOL is that COBOL file processing statements are very simple, with no knowledge of disk head positioning required." But yes, an incredibly good one! Worth filling out the form on the "contact us page" and seeing what they send back. --Guido van Rossum (home page: http://www.python.org/~guido/) From gmcm at hypernet.com Wed Oct 6 18:55:18 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Wed, 6 Oct 1999 12:55:18 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061457.KAA08749@eric.cnri.reston.va.us> References: Your message of "Wed, 06 Oct 1999 13:02:39 +0200." <19991006110240.068AC35BB1E@snelboot.oratrix.nl> Message-ID: <1272894334-31005071@hypernet.com> [Guido, on http://www.cobolscript.com/] > Definitely a joke. Try > > http://www.cobolscript.com/csfaq.htm#question9 > > "One of the other advantages of COBOL is that COBOL file > processing statements are very simple, with no knowledge of disk > head positioning required." > > But yes, an incredibly good one! Worth filling out the form on > the "contact us page" and seeing what they send back. While funny, I can virtually guaruntee these people are serious. It is a common misperception among mainframe/COBOL types that C/Unix has *only* character I/O (which does not exist in the former environment at all - even terminals are block I/O). They regard this as a sign of their vast superiority. (And I dearly wish that born-again "Windoze" bashers be sentenced to work in this environment - they'll soon realize how closely related Windows and Unix are). I did a number of stints introducing client / server to Big Blue shops. (Unix made it's entry *only* because RDBMS's ran on them, and all these shops claimed they would dump Unix as soon as these products worked right on big iron). I *always* had an endless fight with the people who wanted to use COBOL instead of C / C++ (on both the Unix boxes and the PCs). MicroFocus distributed a "white paper" comparing COBOL to C that I came to know very, very well. It came in 4 sections: - the Executive Summary said COBOL was vastly superior in all respects - the White Paper said COBOL was more maintainable (translation - you can hire brown-nosing dorks in suits, instead of geeks in T-shirts) and often had superior performance - the Benchmark showed that C smoked COBOL in absolutely everything except binary search (a COBOL builtin) - the Appendix showed that the C code for "binary search" was a very badly coded linear search. But no shop had ever read past the Executive Summary. And don't forget that there is probably more than one order-of- magnitude more COBOL source out there than source in any other (or maybe all other) language(s). All with no built-in date type; and hardly ever using common date routines either (calling external programs in COBOL is expensive, and awkward, because all variables are global). Y2K-compliant-by-omission-ly y'rs - Gordon From guido at CNRI.Reston.VA.US Wed Oct 6 19:00:50 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 06 Oct 1999 13:00:50 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: Your message of "Wed, 06 Oct 1999 10:57:21 EDT." <199910061457.KAA08749@eric.cnri.reston.va.us> References: <19991006110240.068AC35BB1E@snelboot.oratrix.nl> <199910061457.KAA08749@eric.cnri.reston.va.us> Message-ID: <199910061700.NAA09211@eric.cnri.reston.va.us> Now I'm confused... I typed in the comment box: Very good joke. ROFL. Where do you guys find the time and energy to do this! :-) and got this back: Mr. van Rossum Glad you took the time out of your busy schedule to berate us. We must be doing something right! ;) Chuck Shereda Deskware, Inc. www.deskware.com www.cobolscript.com --Guido van Rossum (home page: http://www.python.org/~guido/) From klm at digicool.com Wed Oct 6 19:19:30 1999 From: klm at digicool.com (klm) Date: Wed, 6 Oct 1999 13:19:30 -0400 (EDT) Subject: [Python-Dev] an alternative language for CP4E, perhaps? In-Reply-To: <199910061700.NAA09211@eric.cnri.reston.va.us> Message-ID: On Wed, 6 Oct 1999, Guido van Rossum wrote: > Now I'm confused... I typed in the comment box: > > [...] > and got this back: > > Mr. van Rossum > > Glad you took the time out of your busy schedule to berate us. > We must be doing something right! ;) > > Chuck Shereda > Deskware, Inc. > www.deskware.com > www.cobolscript.com Apparently deskware is a known, bona fide organization. Considering the massive number of cobol programmers around, and despite how cumbersome the prospect is (and with the advantage of factoring in the things gordon said), i guess someone thinks there's leverage in making cobol a scripting language. I think it's not so different than making interpreted versions of C (but i'm not very C friendly). Ken klm at digicool.com From klm at digicool.com Wed Oct 6 20:05:21 1999 From: klm at digicool.com (Ken Manheimer) Date: Wed, 6 Oct 1999 14:05:21 -0400 Subject: [Python-Dev] an alternative language for CP4E, perhaps? Message-ID: <613145F79272D211914B0020AFF640191D1D2D@gandalf.digicool.com> Concerning the possibility of cobolscript, i wrote: > said), i guess someone thinks there's leverage in making cobol a scripting > language. I think it's not so different than making interpreted versions > of C (but i'm not very C friendly). After posting i thought this might come off as more ignorantly bigoted than i meant for it to seem:-) I was trying to say that C doesn't seem very well suited to scripting/running interpreted, like cobol - not that C is as fraught with ancient and awkward design as cobol (seems). Sigh. Ken klm at digicool.com From mal at lemburg.com Mon Oct 11 22:36:07 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon, 11 Oct 1999 22:36:07 +0200 Subject: [Python-Dev] Walking up the package hierarchy Message-ID: <38024A37.D92E7091@lemburg.com> Hi everybody, while I'm still thinking about writing the import manager, here is a patch that implements the walk-up-the-hierarchy import scheme that got so much positive feedback. I'm intending to use this implementation as proof of concept for the switch to my new package structure, but wouldn't mind seeing something like it the distribution as well ;-) It changes the default import mechanism to work like this: >>> import d try a.b.c.d try a.b.d try a.d try d fail instead of just doing the current two-level lookup: >>> import d try a.b.c.d try d fail As a result, relative imports referring to higher level packages work out of the box without any ugly underscores in the import name. Plus the whole scheme is pretty simple to explain and straightforward. Since the patch is so small, I attached it to this mail. Hope you don't mind. The ZIP archive also contains a sample package which demonstrates the feature. Run Python with -v flag to see how the new scheme works. Feedback is most welcome. I am especially interested whether the scheme breaks any existing packages. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 81 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ -------------- next part -------------- A non-text attachment was scrubbed... Name: walkingimport.zip Type: application/x-zip-compressed Size: 2669 bytes Desc: not available URL: From bwarsaw at cnri.reston.va.us Tue Oct 12 22:21:02 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 12 Oct 1999 16:21:02 -0400 (EDT) Subject: [Python-Dev] string methods branch Message-ID: <14339.38958.882650.342925@anthem.cnri.reston.va.us> Guido has agreed to let me mainline the string methods branch. Those of you on python-checkins should have seen the CVS messages by now. This is a good thing because I think we can all agree we hate CVS branches. For me, that final merge put the nail in the coffin. Anyway, those of you who have put off playing with string methods until now should just be able to do a CVS update, rebuild, and go. You should read the revision log messages for the branch checkins for details of the changes. Let me know if you have any problems. Fred and I will work out changes to the documentation some time soon. >>> sig=['branches','are','only','useful','for','trees','and','streams','ly'] >>> print '-'.join(sig) + " y'rs" -Barry From skip at mojam.com Tue Oct 12 23:03:13 1999 From: skip at mojam.com (Skip Montanaro) Date: Tue, 12 Oct 1999 16:03:13 -0500 Subject: [Python-Dev] new opportunities for obfuscation... ;-) Message-ID: <199910122103.QAA31864@dolphin.mojam.com> Barry's note prompted me to update my Python tree. The result: >>> ".".join(dir("")) 'capitalize.count.endswith.find.index.join.lower.lstrip.replace.rfind.rindex.rstrip.split.startswith.strip.swapcase.translate.upper' A job well done, Barry... Skip Montanaro | http://www.mojam.com/ skip at mojam.com | http://www.musi-cal.com/ 847-971-7098 | Python: Programming the way Guido indented... From mal at lemburg.com Wed Oct 13 14:27:57 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed, 13 Oct 1999 14:27:57 +0200 Subject: [Python-Dev] Walking up the package hierarchy References: <38024A37.D92E7091@lemburg.com> Message-ID: <38047ACD.E716154E@lemburg.com> Strange... I would have thought that this new patch would stir up some cheers or opposition. Has anyone tried it in some real apps ? It would be interesting to see whether it breaks any code in e.g. packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't break anything for my packages or apps. > It changes the default import mechanism to work like this: > > >>> import d > try a.b.c.d > try a.b.d > try a.d > try d > fail > > instead of just doing the current two-level lookup: > > >>> import d > try a.b.c.d > try d > fail -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 79 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Vladimir.Marangozov at inrialpes.fr Thu Oct 14 13:26:11 1999 From: Vladimir.Marangozov at inrialpes.fr (Vladimir Marangozov) Date: Thu, 14 Oct 1999 12:26:11 +0100 (NFT) Subject: [Python-Dev] Walking up the package hierarchy In-Reply-To: <38047ACD.E716154E@lemburg.com> from "M.-A. Lemburg" at "Oct 13, 99 02:27:57 pm" Message-ID: <199910141126.MAA32650@pukapuka.inrialpes.fr> M.-A. Lemburg wrote: > > Strange... I would have thought that this new patch would stir up > some cheers or opposition. Has anyone tried it in some real apps ? Not yet, but this looks better as a default search path. > > It would be interesting to see whether it breaks any code in e.g. > packages such as Pmw, PIL, Zope's packages or NumPy. It doesn't > break anything for my packages or apps. JimF, /F, Guido and other package maintainers could do you a favor by trying your patch ;-) and give us some real feedback on this. -- Vladimir MARANGOZOV | Vladimir.Marangozov at inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one at email.msn.com Fri Oct 15 09:21:15 1999 From: tim_one at email.msn.com (Tim Peters) Date: Fri, 15 Oct 1999 03:21:15 -0400 Subject: [Python-Dev] Corporate installations Message-ID: <000401bf16dd$def75d80$d72d153f@tim> Python is getting used widely enough in my place of employment that people are agitating for a common installation (personal variants are screwing people too often). Various machines are running Win95, Win98, NT, Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke on that whole banana when it's shoved down my throat. For starters, I just need to get it running across Windows platforms. Never looked into this before, and it seems to be exceedingly complicated right out of the box <0.5 wink>: D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON'] >>> Where does all that stuff come from? The first is apparently the current directory; cool. The next 4 appear to come from MarkH's stuff, via the registry. The next 4 appear to come from Python's own registry PythonPath key. The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows -- case differences). The last is another mystery. site.py isn't implicated in any of them (same thing when running with -S). I suppose this is a clue: D:\Python>set PYTHONHOME=ick;fooey D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> sys.path ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'ick', 'fooey\\DLLs', 'ick', 'fooey\\lib', 'ick', 'fooey\\lib\\plat-win', 'ick', 'fooey\\lib\\lib-tk', 'D:\\PYTHON'] >>> Doesn't appear to be sensible, but at least it's predictable . I was surprised to find that setting PYTHONPATH can't be used to override any of this -- it just inserts even more stuff, into sys.path[1:1]. Do I really care? Not much -- the complexity just makes it hard to get a mental model of what Python *thinks* it's trying to accomplish here, and so harder to figure out what needs to be done. Which is pretty severe: "Dragon std" apps must run the same version of Python (which can be local) with the same libraries (which must be network-mounted), regardless of whatever version of Python each user may have built on their own, and regardless of their registry settings or envar values. I think this means I need to distribute a python15.dll and python.exe (via our source control system) into a directory very early on the PATH (other common .exe's are distributed this way, so no big deal), and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the common Dragon dir. Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK. There's no way to do that from within Python, is there? If not, everyone going through "unfortunate" paths in the network will have to set that themselves. Anyone have better ideas? That shouldn't be hard . the-difference-between-one-user-and-two-is-infinite-ly y'rs - tim From mhammond at skippinet.com.au Fri Oct 15 10:02:14 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Fri, 15 Oct 1999 18:02:14 +1000 Subject: [Python-Dev] Corporate installations In-Reply-To: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <000101bf16e3$984577e0$0801a8c0@bobcat> > The 4 after that are a mystery, and duplicate the > preceding 4 (except > for meaningless-- it's Windows -- case differences). Python makes a brave attempt to deduce the PYTHONHOME itself by looking for "well-known" files in the lib directory. Python15.dll uses argv[0] or the result of GetModuleFileName(NULL) (whichever is deemed "better" by the existance of a slash) as the basis for a search for the landmark file. If found, those 4 entries are added and if not they are added relatively (ie ".\lib" in the vain hope they will suddenly become meaningful (which they almost certainly wont) So, when running a .EXE that lives in the main Python directory (such as Python.exe), we get duplicated entries - the ones we deduced, and the ones explicitely in the registry. The problem arises when Python15.dll is used by a .exe that doesnt live in this nice directory - eg Pythonwin, or any other embedding, such as COM objects or peoples custom apps. As argv[0] and GetModuleFileName(NULL) both return a directory where "\lib" appended will not find the landmark file (string.py for windows), you get the useless relative paths added. So, what this means is that Python's strategy for deducing the PythonPath only works for Python.exe and Pythonw.exe - typically the only .exes in the Python directory. So we have the situation where the paths must also be registered in the registry if any other .exe wants to work. > I was surprised to find that setting PYTHONPATH can't be used > to override > any of this -- it just inserts even more stuff, into sys.path[1:1]. Once upon a time Guido stated that PYTHONPATH should override the registry completely. I cant recall the history of this tho, and wouldnt object is that was the case. You are then faced with how to set this env variable (and if you are doing that, why not just set the registry?) > I think this means I need to distribute a python15.dll and > python.exe (via > our source control system) into a directory very early on the > PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC > paths, + the > common Dragon dir. This should be fine - as long as no one needs to run any other .EXE that needs Python15.dll (or unless that other .exe is also in that same directory). > Network name mangling being what it is, I suppose I'll also > need to force > PYTHONCASEOK. There's no way to do that from within Python, > is there? If While my views on this have temepered from illogically ranting to Guido how much I hate it, I still believe this is a mis-feature for Windows. The other alternative is to put Python.exe on the network path, and have your library in a ".\lib" directory under that. Doesnt really solve the problem for your "DragonLib" stuff - Im sure you dont want to stuff _everything_ into a single .lib directory. Also, IMO Python shouldnt bother going sniffing for its library if the registry exists. It just adds time to startup, and if it works is almost guaranteed to be redundant, and if it doesnt work will add useless entries that slow down module searches. However, that still doesnt solve your problem. The final suggestion is to put some of the win32 extensions (specifically, win32api) on a network share along with Python.exe and the standard lib. Then provide a .bat file that actually sets up the registry, and off you go. Sure, people hate the registry, but setting an environment variable is worse. Or an alternative - provide a .reg file with the necessary registry keys - users can "execute" it (double-clicking from explorer, typing the name in start->run, execute "start whatever.reg in their logon script, etc) to have their registry setup. I wish I had a better answer, but can't for the life of me work out what it should be even if MS supported it! Mark. From mal at lemburg.com Fri Oct 15 10:34:14 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri, 15 Oct 1999 10:34:14 +0200 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <3806E706.82FEB673@lemburg.com> Tim Peters wrote: > > Python is getting used widely enough in my place of employment that people > are agitating for a common installation (personal variants are screwing > people too often). Various machines are running Win95, Win98, NT, > Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke > on that whole banana when it's shoved down my throat. > > For starters, I just need to get it running across Windows platforms. Never > looked into this before, and it seems to be exceedingly complicated right > out of the box <0.5 wink>: > > D:\Python>python > Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import sys > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? The first is apparently the current > directory; cool. The next 4 appear to come from MarkH's stuff, via the > registry. The next 4 appear to come from Python's own registry PythonPath > key. The 4 after that are a mystery, and duplicate the preceding 4 (except > for meaningless-- it's Windows -- case differences). The last is > another mystery. site.py isn't implicated in any of them (same thing when > running with -S). On Linux I get: ['', '/home/lemburg/bin', '/home/lemburg/lib', '/home/lemburg/projects', '/home/lemburg/python/Lib/', '/home/lemburg/python/Lib/test', '/home/lemburg/python/Lib/plat-linux2', '/home/lemburg/python/Lib/lib-tk', '/home/lemburg/python/Modules', '/usr/local/lib/python1.5/site-packages'] It seems that the last entry refers to what Python thinks is the standard location for system wide extensions. The first 3 come from my PYTHONPATH setting, the next few are inserted by the Python startup code based on what Python found as landmark to determine PYTHONHOME. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH (other > common .exe's are distributed this way, so no big deal), and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the > common Dragon dir. Sounds reasonable ;-) > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. There's no way to do that from within Python, is there? If > not, everyone going through "unfortunate" paths in the network will have to > set that themselves. If Windows allows writing the process' environment you can set PYTHONCASEOK dynamically: the check queries the environment for the flag prior to every check (instead of doing going the usual internal Python flag way as many of the others do). See Python/import.c:check_case() for details. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 77 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From jim at interet.com Fri Oct 15 17:22:38 1999 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 11:22:38 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> Message-ID: <380746BE.FAE46A0A@interet.com> Tim Peters wrote: > ['', > 'D:\\Python\\win32', > 'D:\\Python\\win32\\lib', > 'D:\\Python', > 'D:\\Python\\Pythonwin', > 'D:\\Python\\Lib\\plat-win', > 'D:\\Python\\Lib', > 'D:\\Python\\DLLs', > 'D:\\Python\\Lib\\lib-tk', > 'D:\\PYTHON\\DLLs', > 'D:\\PYTHON\\lib', > 'D:\\PYTHON\\lib\\plat-win', > 'D:\\PYTHON\\lib\\lib-tk', > 'D:\\PYTHON'] > >>> > > Where does all that stuff come from? Good question. I don't know, and every time I start to think I do, I am wrong. Certainly PYTHONPATH is full of junk on Windows. The point is that PYTHONPATH just doesn't work for commercial installations. Please see these for some discussion: ftp://ftp.interet.com/bootmodule.html ftp://ftp.interet.com/pylib.html I think the solution is to put the library files and packages into archive files (in some format yet to be determined) and find them by looking in the directory of python15.dll and/or python.exe. On Unix there is $prefix, which actually seems to work. > I think this means I need to distribute a python15.dll and python.exe (via > our source control system) into a directory very early on the PATH Yes, that is a good start. Just understand that *.pyd and and DLL's which are imported (instead of linked against) are found from PYTHONPATH, not PATH. Also you will need a valid PATH on all PC's which is quite a bother. An alternative is to use the Wise installer to set up icons for your apps. Real Windows apps don't use PATH. We use Wise for internal as well as external apps. Note that if you import a module "import foo", and foo lives in "foo.dll", then on Windows, PYTHONPATH is searched, and the standard Windows DLL path is not searched. That means you can't use standard Windows locations for DLL's which are dynamically imported. This is an error and should be fixed. > and add a > sitecustomize.py that replaces all of sys.path with the Big Four > (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) The problem is that you already need a valid PYTHONPATH to find sitecustomize.py. Better is to create a custom python15.dll with sitecustomize.py, exceptions.py and site.py (all needed during boot) frozen in as frozen modules. In our office I freeze in other library files too. > Network name mangling being what it is, I suppose I'll also need to force > PYTHONCASEOK. I don't seem to need that on 95/98/NT. Network names shouldn't get mangled on these systems. I guess you mean lack of case sensitivity, but just make sure the case is correct in the Lib directory. This is another reason to prefer archive files anyway. But no, you shouldn't need PYTHONCASEOK. > Anyone have better ideas? That shouldn't be hard . Yes, this is a major problem with Python's acceptance for commercial apps (and I include internal production code as an app) so lets figure out what to do and fix it. Jim Ahlstrom From jim at interet.com Fri Oct 15 20:19:41 1999 From: jim at interet.com (James C. Ahlstrom) Date: Fri, 15 Oct 1999 14:19:41 -0400 Subject: [Python-Dev] Corporate installations References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> Message-ID: <3807703D.9FD09C5B@interet.com> "James C. Ahlstrom" wrote: Sorry, correct URL is: ftp://ftp.interet.com/pub/bootmodule.html ftp://ftp.interet.com/pub/pylib.htm Jim Ahlstrom From fredrik at pythonware.com Fri Oct 15 21:17:05 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:17:05 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> Message-ID: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> while doing the final checks for my upcoming standard library guide, I thought I'd check what had changed in the CVS version. some old (1.5.1) junk was still to be found in the lib-old subdirectory, but certain 1.5.2 things seem to have vanished into thin air. like find.py, for example. does anyone know where it is? after all, it's kinda useful, and I just pointed someone to it, only to find that he didn't have it on his machine... is there an official list of totally deprecated modules somewhere? From fdrake at acm.org Fri Oct 15 21:44:29 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 15 Oct 1999 15:44:29 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> Message-ID: <14343.33821.523179.786228@weyr.cnri.reston.va.us> Fredrik Lundh writes: > some old (1.5.1) junk was still to be found in the > lib-old subdirectory, but certain 1.5.2 things seem > to have vanished into thin air. > > like find.py, for example. does anyone know > where it is? after all, it's kinda useful, and I It should be in lib-old. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fredrik at pythonware.com Fri Oct 15 21:58:17 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Fri, 15 Oct 1999 21:58:17 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim><380746BE.FAE46A0A@interet.com><3807703D.9FD09C5B@interet.com><006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> Message-ID: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Fred L. Drake, Jr. wrote: > > like find.py, for example. does anyone know > > where it is? after all, it's kinda useful, and I > > It should be in lib-old. "should" as in "is already there" or "oops, I'll fix it" ? :-) [fredrik at brain BleedingEdge]$ ls python/dist/src/Lib/lib-old/ CVS codehack.py newdir.py rand.py whatsound.py Para.py fmt.py ni.py tb.py zmod.py addpack.py lockfile.py poly.py util.py (sure looks like "oops" to me...) From fdrake at acm.org Fri Oct 15 22:41:14 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri, 15 Oct 1999 16:41:14 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> Message-ID: <14343.37226.964388.867049@weyr.cnri.reston.va.us> Fredrik Lundh writes: > "should" as in "is already there" or > "oops, I'll fix it" ? :-) It's certainly in lib-old/ in the CVS repository. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tismer at appliedbiometrics.com Fri Oct 15 23:55:36 1999 From: tismer at appliedbiometrics.com (Christian Tismer) Date: Fri, 15 Oct 1999 23:55:36 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> Message-ID: <3807A2D8.7E7F91F8@appliedbiometrics.com> "Fred L. Drake, Jr." wrote: > > Fredrik Lundh writes: > > "should" as in "is already there" or > > "oops, I'll fix it" ? :-) > > It's certainly in lib-old/ in the CVS repository. Sorry. Definately certainly not. But a find.py is in Demo/threads. Fred (any of both :) did you mean that? ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net 10553 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home From fredrik at pythonware.com Mon Oct 18 09:31:16 1999 From: fredrik at pythonware.com (Fredrik Lundh) Date: Mon, 18 Oct 1999 09:31:16 +0200 Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> Message-ID: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> > > > "should" as in "is already there" or > > > "oops, I'll fix it" ? :-) > > > > It's certainly in lib-old/ in the CVS repository. > > Sorry. Definately certainly not. > > But a find.py is in Demo/threads. > Fred (any of both :) did you mean that? I cannot see any "find.py" in either Lib (where it is in all my copies of 1.5.2) or Lib/lib-old. fwiw, I can think of a few dozen other standard library modules that I'd remove before this one. cannot we put it back? please? :-) (after all, it's been a reoccuring theme on comp.lang.python lately. and 1.5.2+ breaks my new book...). From fdrake at acm.org Mon Oct 18 16:31:34 1999 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon, 18 Oct 1999 10:31:34 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? In-Reply-To: <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <14347.12102.276497.310651@weyr.cnri.reston.va.us> Fredrik Lundh writes: > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It most certainly *should* be appearing in lib-old; I just checked the internal CVS repository and it's really there. Perhaps the anonymous mirror isn't right? (Barry, can you check this? I don't even know where it is, much less whether I can see those directories.) > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) That's up to Guido, not me. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From guido at CNRI.Reston.VA.US Mon Oct 18 16:56:55 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 18 Oct 1999 10:56:55 -0400 Subject: [Python-Dev] what happened to find.py? In-Reply-To: Your message of "Mon, 18 Oct 1999 09:31:16 +0200." <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> Message-ID: <199910181456.KAA22936@eric.cnri.reston.va.us> > I cannot see any "find.py" in either Lib (where it > is in all my copies of 1.5.2) or Lib/lib-old. It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, we'll ask Barry to investigate. Maybe the branching messed things up? > fwiw, I can think of a few dozen other standard > library modules that I'd remove before this one. > cannot we put it back? please? :-) It's better (and more illustrative) to use os.walk() to do this thing. > (after all, it's been a reoccuring theme on > comp.lang.python lately. and 1.5.2+ breaks > my new book...). Good thing it isn't printed yet. :-) --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw at cnri.reston.va.us Mon Oct 18 17:35:04 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Mon, 18 Oct 1999 11:35:04 -0400 (EDT) Subject: [Python-Dev] what happened to find.py? References: <000401bf16dd$def75d80$d72d153f@tim> <380746BE.FAE46A0A@interet.com> <3807703D.9FD09C5B@interet.com> <006c01bf1741$de8d0480$f29b12c2@secret.pythonware.com> <14343.33821.523179.786228@weyr.cnri.reston.va.us> <000b01bf1747$a03b2210$f29b12c2@secret.pythonware.com> <14343.37226.964388.867049@weyr.cnri.reston.va.us> <3807A2D8.7E7F91F8@appliedbiometrics.com> <00b401bf193a$c4e43170$f29b12c2@secret.pythonware.com> <199910181456.KAA22936@eric.cnri.reston.va.us> Message-ID: <14347.15912.178116.186186@anthem.cnri.reston.va.us> >>>>> "Guido" == Guido van Rossum writes: Guido> It *is* in Lib/lib-old. Maybe the CVS mirror is messed up, Guido> we'll ask Barry to investigate. Maybe the branching messed Guido> things up? Somehow the mirror was out of date. Perhaps the branch merge got it out of whack, but in any case, I've done a top-level resync. find.py is definitely in the repository under lib-old now! Hope that helps, -Barry From bwarsaw at cnri.reston.va.us Tue Oct 19 17:30:01 1999 From: bwarsaw at cnri.reston.va.us (Barry A. Warsaw) Date: Tue, 19 Oct 1999 11:30:01 -0400 (EDT) Subject: [Python-Dev] forwarded message from Greg Rose Message-ID: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Folks, I'm resending this message here for Greg Rose. If anybody can help him out, please respond to ggr at qualcomm.com (not to me). Greg, if you still get no response, then I suggest sending the mssage to greater python-list at python.org. There's gotta be /somebody/ out there who is interested in participating. -Barry ------- start of forwarded message (RFC 934 encapsulation) ------- From: Greg Rose To: bwarsaw at python.org Subject: Re: python advocate in Perl/Python/Tcl bakeoff Date: Tue, 19 Oct 1999 20:28:37 +1000 X-Sender: ggr2 at avalon.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 At 17:07 30/09/1999 -0400, you wrote: >Hope that helps. If neither of these guys can do it, and can't >suggest someone who can, let me know and we'll post an announcement on >all the usual Python haunts. Well, as they say, those who volunteer end up doing things... I've tried both of your associates, and about three or four others who were recommended, and have struck out. I'd really appreciate your help trying to find someone competent to do this. Bear in mind that the audience is sysadmins, not generic programmers. thanks in advance, Greg. Here's the text I've been sending out, but you should feel free to modify non-factual stuff: Long ago there was a shell/perl/awk bakeoff invited talk at a USENIX conference somewhere or other. It was fun for all involved, and was very well received. We're looking to do something similar at the LISA conference in Seattle. You have been recommended as Python advocate. It would be on thursday 11th november. The idea would be to have a moderator and three advocates, and a slightly rowdy audience. We'd ask each advocate to nominate in advance some simple sysadmin task which shows their language to its advantage, and also to do the solutions to the other two's tasks... then there'd be some room for (presubmitted) tasks from the audience to be solved on the fly. Any suggestions you have regarding how to make it work would be appreciated. Are you intending to attend LISA? Would you be willing to do this? (We have Tom Christiansen for perl and Brent Welch for Tcl/Tk.) Greg Rose INTERNET: ggr at Qualcomm.com Qualcomm Australia VOICE: +61-2-9181-4851 FAX: +61-2-9181-5470 Suite 410, Birkenhead Point, http://people.qualcomm.com/ggr/ Drummoyne NSW 2047 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C ------- end ------- From guido at CNRI.Reston.VA.US Tue Oct 19 17:49:10 1999 From: guido at CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 19 Oct 1999 11:49:10 -0400 Subject: [Python-Dev] forwarded message from Greg Rose In-Reply-To: Your message of "Tue, 19 Oct 1999 11:30:01 EDT." <14348.36473.112615.887932@anthem.cnri.reston.va.us> References: <14348.36473.112615.887932@anthem.cnri.reston.va.us> Message-ID: <199910191549.LAA25773@eric.cnri.reston.va.us> Alas, I'll be at SD99 East in DC that week, teaching Python CGI programming. See http://www.python.org/Events.html --Guido van Rossum (home page: http://www.python.org/~guido/) From da at ski.org Tue Oct 19 18:58:34 1999 From: da at ski.org (David Ascher) Date: Tue, 19 Oct 1999 09:58:34 -0700 (Pacific Daylight Time) Subject: [Python-Dev] Irrelevant but very informative piece of patent law Message-ID: http://slashdot.org/features/99/10/19/1032254.shtml Very well written, too. Many many standard deviations away from standard slashdot fare. --da From mhammond at skippinet.com.au Sat Oct 30 01:11:54 1999 From: mhammond at skippinet.com.au (Mark Hammond) Date: Sat, 30 Oct 1999 09:11:54 +1000 Subject: [Python-Dev] Embedding Python when using different calling conventions. Message-ID: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> This is a bit yucky, but still a valid problem. Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help with a problem. He has an existing Windows project that he wishes to use Python in. This project does not use the standard __cdecl calling convention that Python uses, for various reasons known only to him. As it is an existing project and quite probably a large, complex one, I am willing to accept that moving his existing project to match Python's calling convention is not reasonable. I also feel for him, as I have personally battled this - both with Python and with other projects. He has requested that Python explicitely declare the calling convention it uses. Thus, it can be embedded in any project. He wants a new macro. Eg: DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); becomes DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); I suggested embedding the calling convention in with the DL_IMPORT macro, but he pointed out this macro is also used for variables, where the convention syntax is illegal. To my mind this is reasonable (maybe not the spelling, but definately the intent). Any thoughts? Mark. From mal at lemburg.com Sat Oct 30 10:46:30 1999 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat, 30 Oct 1999 10:46:30 +0200 Subject: [Python-Dev] Embedding Python when using different calling conventions. References: <004201bf2262$fe5cfeb0$0501a8c0@bobcat> Message-ID: <381AB066.B54A47E0@lemburg.com> Mark Hammond wrote: > > This is a bit yucky, but still a valid problem. > > Malte Kroeger [kroeger at bigfoot.com] recently posted to python-help > with a problem. He has an existing Windows project that he wishes to > use Python in. This project does not use the standard __cdecl calling > convention that Python uses, for various reasons known only to him. > As it is an existing project and quite probably a large, complex one, > I am willing to accept that moving his existing project to match > Python's calling convention is not reasonable. I also feel for him, > as I have personally battled this - both with Python and with other > projects. Isn't the default calling scheme selectable via compiler switches ? I remember that this was the case with the IBM compiler on OS/2. > He has requested that Python explicitely declare the calling > convention it uses. Thus, it can be embedded in any project. > > He wants a new macro. Eg: > > DL_IMPORT(int) PyRun_SimpleFile Py_PROTO((FILE *, char *)); > becomes > DL_IMPORT(int) CALLCONV PyRun_SimpleFile Py_PROTO((FILE *, char *)); > > I suggested embedding the calling convention in with the DL_IMPORT > macro, but he pointed out this macro is also used for variables, where > the convention syntax is illegal. Perhaps switching to DL_IMPORT_FUNCTION(int) for functions would be a better idea. This would leave the previous definition of DL_IMPORT untouched (which is used by a few extensions too). OTOH, we could take chance to reorganize these macros from bottom up: when I started coding extensions I found them not very useful mostly because I didn't have control over them meaning "export this symbol" or "import the symbol". Especially the DL_IMPORT macro is strange because it seems to handle both import *and* export depending on whether Python is compiled or not. FYI, I'm using these macros for the mx extensions: /* Macros to control export and import of DLL symbols. We use our own definitions since Python's don't allow specifying both imported and exported symbols at the same time. */ /* Macro to "mark" a symbol for DLL export */ #if (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_EXPORT(type) extern "C" type __declspec(dllexport) # else # define MX_EXPORT(type) extern type __declspec(dllexport) # endif #elif defined(__WATCOMC__) # define MX_EXPORT(type) extern type __export #else # define MX_EXPORT(type) extern type #endif /* Macro to "mark" a symbol for DLL import */ #if defined(__BORLANDC__) # define MX_IMPORT(type) extern type __import #elif (defined(_MSC_VER) && _MSC_VER > 850 \ || defined(__MINGW32__) || defined(__BEOS__)) # ifdef __cplusplus # define MX_IMPORT(type) extern "C" type __declspec(dllimport) # else # define MX_IMPORT(type) extern type __declspec(dllimport) # endif #else # define MX_IMPORT(type) extern type #endif plus these kind of defines in the extension header files: #ifdef MX_BUILDING_MXDATETIME # define MXDATETIME_EXTERNALIZE MX_EXPORT #else # define MXDATETIME_EXTERNALIZE MX_IMPORT #endif Note that MX_EXPORT always defines export symbols and MX_IMPORT always means "import the symbol". The *_EXTERNALIZE macro decides which form to take depending on whether the header file is used to compile the extension itself or using the extension. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 62 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From gmcm at hypernet.com Sun Oct 31 16:59:16 1999 From: gmcm at hypernet.com (Gordon McMillan) Date: Sun, 31 Oct 1999 10:59:16 -0500 Subject: [Python-Dev] dircache.py Message-ID: <1270737688-19939033@hypernet.com> Pursuant to my volunteering to implement Guido's plan to combine cmp.py, cmpcache.py, dircmp.py and dircache.py into filecmp.py, I did some investigating of dircache.py. I find it completely unreliable. On my NT box, the mtime of the directory is updated (on average) 2 secs after a file is added, but within 10 tries, there's always one in which it takes more than 100 secs (and my test script quits). My Linux box hardly ever detects a change within 100 secs. I've tried a number of ways of testing this ("this" being checking for a change in the mtime of the directory), the latest of which is below. Even if dircache can be made to work reliably and surprise-free on some platforms, I doubt it can be done cross-platform. So I'd recommend that it just get dropped. Comments? --------------------------------------------------- import os import sys import time d = os.getcwd() atimes = [] def test(): m = os.stat(d)[8] for i in range(10): fnm = 's%d.tmp' % i open(fnm,'w').write('dummy - delete me') for j in range(10000): newm = os.stat(d)[8] if newm != m: atimes.append(j*0.01) m = newm break time.sleep(0.01) else: print "At round %d, failed to detect add within %3.2f secs" % (i, j*0.01) break def report(): import operator if atimes: print "detect adds: min= %3.2f max= %3.2f avg= %3.2f" % (min(atimes), max(atimes), reduce(operator.add, atimes, 0.0)/len(atimes)) else: print "no successfully detected adds" test() report() - Gordon