Mailman 3 December 1999 - Python-Dev

re: Open Source design competition / Python / software tools
by gvwilson＠nevex.com 24 Dec '99

24 Dec '99

Hi, folks. I hope you don't mind another mail out of the blue, but I got notice on Saturday that the Department of Energy is giving me $860K over two years to support development of easier-to-use software engineering tools. All of the work will be Open Source, and will be done in Python, with a strong emphasis on design, testing, and documentation. The project's long-term objective is to encourage scientists and engineers to treat programs in the same way as they do other experiments, i.e. to calibrate, test, peer review, and so on. To kick-start things, we're going to be holding a two-round design competition. Anyone (individual or team, professional or student) can submit a short entry for the first round; the judges will pick four candidates to go forward in each of four categories, and those individuals or teams will be asked to submit full entries. The four categories are: * an issue tracking system to replace Gnats and Bugzilla; * a build system to replace make; * a platform inspection and configuration system to replace autoconf; and * a testing framework to replace XUnit, Expect, and DejaGnu. Would you be interested in participating in any way---judging, entering a design, critiquing things from the pointer of view of end users, or anything else? I realize that you're probably up past your eyeballs with work, and that the money on offer is nothing special, but I think this could be a lot of fun, and could help to shift the emphasis of the Open Source community from hacking to design (both by drawing attention to, and rewarding, design, and by creating a corpus of examples and commentary for programmers to refer to). It could also make life a lot easier for computational scientists and engineers... Please let me know if you'd like to be involved, or if you'd like more information than is contained in the FAQ (attached). Timescales are a bit tight---I'd like to be able to make an announcement on January 14---but I'll be reading email at this address several times a day during the holiday. I look forward to hearing from you, Greg Wilson p.s. please note that the attached FAQ is a first draft; I'd be grateful if you could show it to anyone you think might be interested, but I'd also be grateful if you wouldn't broadcast it until it's gone through one more editing pass.

4 6

Re:[Python-Dev] Fixed Decimal types
by Da Silva, Mike 24 Dec '99

24 Dec '99

Andy Robinson wrote: For the work I do, simply taking the precision of the most precise input (4.00L)would do the trick, but your answer (4.0000L) is purer. We should provide a rounding function, and in practice anyone using such a function would round (or floor, or ceiling) to get to the desired precision immediately. I'm not sure on division either but I'm sure there are precedents to look at. The AS400 provides a useful example of the right way to do scaled decimals. In the RPG programming language, all internal calculations (i.e. multiplication, division) are performed to the maximum precision of the intermediate result (in the multiplication example below), the intermediate result would be 4.0000L. When the intermediate result is assigned to the target scaled decimal number, the decimal precision is automatically extended or truncated to fit the target precision. One extra wrinkle in all of this is the option to "half-adjust" the intermediate value on assignment; that is to apply automatic 5/4 rounding to the precision of the target. So, if the target field is defined as numeric(4,2), the result will be 4.00L. These are probably the kind of semantics that a scaled decimal type would require in Python also; i.e. allow unlimited precision in intermediate calculations, with a sensible set of rules for assignment to a variable of different scale and precision. However, unlike RPG, we should probably ensure that attempts to overflow or underflow the scale result in NaN or Overflow conditions, rather than assuming the user is right and losing the significant digits. Regards, Mike da Silva

3 2

Re: [Python-Dev] Fixed-decimal types
by Andy Robinson 23 Dec '99

23 Dec '99

--- Guido van Rossum <guido(a)CNRI.Reston.VA.US> wrote: > What would be scale of the product of two > fixed-decimal numbers? > E.g. is 2.00L * 2.00L equal to 4.0000L, or equal to > 4.00L? There are > arguments for either. Same question for division > (harder, I think). Most commonly one is trying to avoid rounding errors when dealing with money - a few cents rounding error tends to result in a few billable hours with the accountants at the end of the year! SQL dialects and type-safe languages would make you specify the precision of the variable to be assigned, so the issue does not arise for other languages. For the work I do, simply taking the precision of the most precise input (4.00L)would do the trick, but your answer (4.0000L) is purer. We should provide a rounding function, and in practice anyone using such a function would round (or floor, or ceiling) to get to the desired precision immediately. I'm not sure on division either but I'm sure there are precedents to look at. On the subject of adding new types to the standard library, what are the plans on dates and times? Would a cut-down mxDateTime ever be considered? It is fully Open Source (unlike mxODBC) and was designed for the DBAPI. Regards, Andy ===== Andy Robinson Robinson Analytics Ltd. ------------------ My opinions are the official policy of Robinson Analytics Ltd. They just vary from day to day. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

2 1

Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Lib getopt.py,1.7,1.8
by Jack Jansen 23 Dec '99

23 Dec '99

> Vladimir.Marangozov(a)inrialpes.fr: > > > Yes. Besides, I still think that string-based exceptions are just > > convenient for quick & dirty, throw-away test scripts. > > They have a hard-to-understand quirk though: the id() of the string is > used to check rather than its value, so that except "foo" doesn't > necessarily catch raise "foo"; but due to various optimization, this > usually works, and people get bent out of shape when it doesn't. I sort-of use this feature when I'm debugging: if I want to know what happens in an exception that is usually caught somewhere higher up in the call stack I simply put quotes around the exception name and the exception will happen uncaught. The same trick works for except: clauses. -- 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

1 0

Re: [Python-Dev] Batteries Included?
by Jack Jansen 21 Dec '99

21 Dec '99

> IMHO the "much simpler freezing process" is archive files. A simple > script can build them, imputil can import them, and the only > remaining problem is to find them. Please see: Archive files solves the problem for Python modules. But that leaves the problem of dynamically loaded modules. And resources for dialogs and such, if you use native GUI stuff on Mac or Windows. And most serious applications that I've seen (GRiNS and Zope, to name two, Mailman is the only exception I can think of) depend on non-standard plugin modules. -- 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

2 1

posix module
by Fred L. Drake, Jr. 21 Dec '99

21 Dec '99

Ok, I think I'm done with the posix module updates, modulo bugs and additional symbols for the *conf*() tables. That leaves us with the following status for interfaces that Andrew brought up in the message that started this spate of additions: Worth adding? ============= opendir(), readdir(), closedir() -- not added The only thing these give us that os.listdir() doesn't is the inode numbers. Unless someone actually wants those, it's not worth having. Worth adding: ============= abort() -- added ctermid(), ctermid_r() -- added fpathconf(fd, name) -- added getlogin() -- added getgroups(gidsetsize, grouplist) -- added pathconf(path, name) -- added sysconf(int name) -- added; also added confstr(int name) Not worth adding: ================= clearerr() -- not added cuserid() -- not added difftime -- not added tmpfile(), tmpnam() -- added, also tempnam() mblen(), mbstowcs(), mbtowc(), wcstombs(), wctomb() -- not added -Fred -- Fred L. Drake, Jr. <fdrake(a)acm.org> Corporation for National Research Initiatives

2 2

Re: [Python-Dev] Batteries Included?
by Jack Jansen 20 Dec '99

20 Dec '99

Recently, Jeremy Hylton <jeremy(a)cnri.reston.va.us> said: > Perhaps the right long-term solution (post-distutils) is to split > Python into a core architected by Guido and a bazaar-style standard > library maintained in a more apache-style. I can't help feeling uncomfortable with this. I've had quite some work to get an Apache with SSL up and running, even though someone gave me quite precise instructions. With Perl I fared even worse, despite their distutils-like package, when I wanted to try a PalmPilot package for Unix that needed Perl. I finally had to give up after quite some effort because the addon installers kept finding the older version of Perl that the system mgr had installed in stead of my newer version. I think distutils will be wonderful for us, the Python community, but something more RedHattish is needed for the general world who just want Python plus a certain set of extensions because some application needs it, so they can just download a fresh copy of ParrotPython 3.4.4 and know the application will work, without interfering with another application that happens to use Inquisition 1a5 and lives elsewhere on the disk. And maybe the answer is a much simpler freezing process, like MacPython BuildApplication where any Python user can drop a script on it and end up with a fully self-contained app guaranteed (well.... No reports to the contrary have been heard so far, at least:-) to contain everything needed and not interfere with an existing MacPython installation (or be interfered with by it). Then a popular app will have prebuilt binaries available for all platforms quickly, made by the Python community, and the enduser interested in the app but not in Python can simply download that. -- 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

2 1

Year 2000 O'Reilly Python Conference
by David Ascher 19 Dec '99

19 Dec '99

I just got off the phone with someone at O'Reilly, who is starting to plan the next O'Reilly Open Source Convention. I've agreed to be the chair of the Python conference, just so that there are no delays in getting the conference organized. If someone feels that I should not be chair, speak now and we can figure out who takes the 'job'. There are short-term and long-term issues to discuss: Short term: - We need a program committee -- If you're interested in being on said committee or know someone who should be, let me know. I'd like to get representatives from various subconstituencies on there (web types, zope types, business types, scientist types, linux types, hackers, etc.) - The call for papers is going on the O'Reilly website soon. I will try and get them to pass things by me first, but if we want to emphasize specific kinds of paper submissions, we need to decide that soon. - Greg or Barry, is it possible for one of you to setup a mailman mailing list which will be used by the program committee? eGroups is easy for me to setup, but lots of people hated it last year. I don't want to pollute python-dev with conference discussions. Longer term: - The schedule for the conference is (supposedly) going to be the same as last year. conference-wide keynotes at the beginning of both days, and 4x90minute segments. - We have two parallel tracks - We have 4 half-day tutorial slots - All of the paper materials have to be 'in' by March 1. We need to decide how much time we need to go through the review/revision process ourselves. In other words, the deadline for submissions is up to us, but we don't have that much time. --david ascher

2 2

Batteries Included?
by Guido van Rossum 18 Dec '99

18 Dec '99

I like the batteries included approach, but I also feel resistence against including stuff I cannot maintain. The XML code base is a point in case; I don't understand enough about XML. (I just read that xmllib.py is "illegal". Jeez! What happened? Did Congress pass a law against it?) I think it may be time for separate Python distributions, like Linux -- I can concentrate on the core, and keep it really small; others can make all-encompassing distributions. There are currently some drawbacks to this approach: non-core modules have less status; and the documentation process is fundamentally different for core and non-core modules. There's also the version dependency stuff, but I think resolving that is the responsibility of the distribution makers. I think the status problem will be gone once there is a respected distribution -- then you derive status from being in that distribution, rather than from being in the core distribution. (Well, you would still derive status from being in the core, but it would be much harder to obtain, since I can set a much higher standard.) The documentation problem is the one that's left. I think the doc-sig may be on its way as we speak to solve this, though. Fred? This isn't rocket science. Red Hat Python? I'm all for it! :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

6 6

Re: [Distutils] ANNOUNCE: Distutils 0.1.2 released
by Greg Stein 17 Dec '99

17 Dec '99

On Thu, 16 Dec 1999, Guido van Rossum wrote: >... > I realize it's just a rant. In this case (distutils) your advice is > correct. (I usually paraphrase it as "release early, release often".) True. I prefer that phrase, too, but I used it on JimA earlier in the day or the previous day. I didn't want to sound like a broken record :-). But that is why I moved into <rant> mode... it seems like the mindset was spreading :-) I've railed at AMK for it, too :-), when he was talking about 0.5.1pre1 or whatever, rather than just releasing 0.5.1 and doing an 0.5.2 if there was a problem. > However there are other situations, like core Python itself, where > it's really useful to have stable releases -- if only for those users > who won't touch anything with "beta" in its name. I still hear from > people who haven't upgraded to 1.5.2. But this doesn't explain why there isn't a 1.5.3b1, 1.5.3b2, etc. Or 1.6.0a1 or whatever (maybe "d" or "r" for dev release, as opposed to alpha). There are some people would like the releases rather than using CVS. Some people can't even use CVS because of firewall issues. Of course, an alternative is snapshot-tarballs of the CVS repository. But a snapshot could *really* be broken; something like 1.6.0d1 says "well, it's a development release, but I've hit a good point between some changes." > I wonder if perhaps for those cases (where there's a demand for stable > releases) some other strategy could be used? Such as labeling > releases "stable" after the fact? Or what Linus seems to do with the > Linux kernel (even = stable, odd = development; or was it the other > way around?). Yes: even are stable (e.g. 1.0, 1.2, 2.0, 2.2). The odd numbers are for development. Linus is currently working 2.3.x, but declared in the past couple days that things will be wrapping up to move towards 2.4. Once he thinks it is ready, he'll start off with 2.4.0pre1, pre2, pre3... At some point the "pre" suffix will drop and 2.4.0 will be released. You might have a bit of problem using that mechanism since the current stable release is 1.5 :-). Once 1.6 hits the street, then you could start doing 1.9 releases (dev) and shift to 2.0 once it is "stable". Cheers, -g -- Greg Stein, http://www.lyra.org/

3 3