Python-Dev October 1999

python-dev@python.org

18 participants
16 discussions

Re: [Python-Dev] an alternative language for CP4E, perhaps?

by Jack Jansen

> 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(a)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

21 years, 7 months

an alternative language for CP4E, perhaps?

by Fredrik Lundh

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? :-) </F>

21 years, 7 months

Alternative Approach to Relative Imports

by M.-A. Lemburg

Hi everybody, I'm currently busy converting my code to use mx.DateTime instead of just DateTime and must say that this is a real pain. Now instead of reviving the __ discussion I'd like to turn to what could be a workable compromise (I think Jim proposed something along these lines already and there was similar code in ni.py). The proposal is really only an addition to the lookup scheme used by the importer. No additional syntax is involved and best of all, it is backward compatible... The current lookup does the following if you want to import a module E from module A.B.C.D: 1. check A.B.C.E 2. check E 3. fail Now instead of failing we could add a lookup method that walks up the package structure: 3. check A.B.E 4. check A.E [5. check E -- already done] 6. fail so that the complete scheme looks like this: 1. check A.B.C.E 2. check E 3. check A.B.E 4. check A.E [5. check E -- already done] 6. fail That way I could leave intra-mx-package imports untouched and still have the convenience of achieving the goal of making my mx subpackages work in the mx context *plus* in the top-level context thus allowing a backward compatible and flexible setup for mx* users. Note that the scheme finds exactly the same modules it did previously, plus perhaps some more (which is intended), and it does not involve any search path hacks. How is that for a compromise ? [Ducking for cover ;-)] -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 100 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

21 years, 7 months

ESR on slashdot

by Mark Hammond

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.

21 years, 7 months

Naming and Binding of Objects (was: Relative Package Imports)

by Vladimir Marangozov

The relative import thread has hit me with full force. I'm not sure I understand all of what has been said, but since I know this is mainly a naming issue, I want to point you to one of the best CS papers I have had in my hands. It's not really my style to recommend references, but this one should be of major interest to this audience (and Python respectively): Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978. It's not available online (it was written on a typewriter), so I'd be happy to send a hard copy of it to anyone who raises a hand in private mail (or cannot find LNCS 60). It's simply a jewel. This guy has understood everything (and I suspect Guido has read this one before implementing Python ;-) -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

21 years, 7 months

getopt helper?

by Mark Hammond

A little thought I have had a few times now, so it is time to pass it on for comment. Basically _every_ time I use getopt, I write code like this: import getopt try: opts, args = getopt.getopt(sys.argv[1:], "slc:d:e:") except getopt.error, why: print why print usage % (os.path.basename(sys.argv[0],)) sys.exit(1) Every single time. I have never used getopt without this code. How about we put this functionality into getopt itself? It could be triggered either by adding a new "usage" param defaulting to None, or by adding a new entry point. ie: opts, args = getopt.getopt(sys.argv[1:], "slc:d:e:", usage=usage) or opts, args = getopt.getoptex(sys.argv[1:], "slc:d:e:", usage=usage) I know it is fairly trivial, but IMO is such a useful module and the pattern is used so regularly that is seems to make sense to add it. Any thoughts? If it is seen favourably, how should we spell it? Mark.

21 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 1999