Mailman 3 July 2001 - Python-announce-list

www.python.org is down
by Guido van Rossum July 30, 2001

July 30, 2001

We have a broken hard drive on the machine that is www.python.org. CNRI claims there is no spare drive. It may be a while before we resolve this. In the mean time, here's a mirror: http://mirrors.ccs.neu.edu/Python/www.python.org/ Here's a list of mirrors: http://mirrors.ccs.neu.edu/Python/www.python.org/Mirrors.html --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Roundup issue tracker version 0.2.3
by Richard Jones July 30, 2001

July 30, 2001

Roundup 0.2.3 - an issue tracking system Changes: See the release notes on the website or the CHANGES.txt distributed with the source. This is a feature-add and bug-fix release. Users who downloaded 0.2.2 should read CHANGES.txt and upgrade immediately. Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.0+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/ -- Richard Jones richard(a)bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)

1 0

ANN: Third alpha release of Jython-2.1
by bckfnn＠worldonline.dk July 29, 2001

July 29, 2001

I am happy to announce the third alpha release of Jython 2.1. Jython is a Java implementation of the Python programming language. It allows users to compile Python source code to Java byte codes, and run the resulting bytecodes on any Java Virtual Machine. It is a very seamless and smooth integration with Java: from Python you have complete access to all Java libraries, can build applets, can integrate with Java beans, and can subclass Java classes in Python and vice versa. Like Python, and unlike Java, Jython can also be used interactively: just type some Jython code at the prompt and see the results immediately. A java installer is available for download at the Jython website: http://www.jython.org/ Installation on version 2.1a3 is similar to version 2.0. Further information and tips on installation is available at: http://www.jython.org/install.html Jython 2.1 aims to be feature compatible with Python 2.1.1 and among the new feature are: - A settable console encoding will allow windows users to enter national characters at the command prompt. - The names of zip- and jarfiles can be added to sys.path. A complete list of changes and differences are available here: http://www.jython.org/NEWS.html A list of fixed bugs can be found here: http://sourceforge.net/tracker/?group_id=12867&atid=112867 Change the Status input box to "Closed" and the Group input box to "Fixed in 2.1a3" and press the "Browse" button. Bugs can be reported to the bug manager on SourceForge: http://sourceforge.net/bugs/?group_id=12867 Cheers, the jython-developers

1 0

Roundup issue tracker version 0.2.2
by Richard Jones July 29, 2001

July 29, 2001

Roundup 0.2.2 - an issue tracking system Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this release. The contact for this project is richard(a)sourceforge.net. Roundup manages a number of issues (with properties such as "description", "priority", and so on) and provides the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.0+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/ Changes: See the release notes on the website or the CHANGES.txt distributed with the source. This is the first "public" release.

1 0

Changing the Division Operator -- PEP 238, rev 1.12
by Guido van Rossum July 27, 2001

July 27, 2001

Here's a new revision of PEP 238. I've incorporated clarifications of issues that were brought up during the discussion of rev 1.10 -- from typos via rewording of ambiguous phrasing to the addition of new open issues. I've decided not to go for the "quotient and ratio" terminology -- my rationale is in the PEP. IF YOU WANT ME TO SEE YOUR COMMENTS, FOLLOW UP TO THE COPY OF THIS ARTICLE IN COMP.LANG.PYTHON. I cannot follow all of c.l.py, but I will follow this one thread. Please don't fragment the thread -- I won't see other threads, guaranteed. --Guido van Rossum (home page: http://www.python.org/~guido/) PEP: 238 Title: Changing the Division Operator Version: $Revision: 1.12 $ Author: pep(a)zadka.site.co.il (Moshe Zadka), guido(a)python.org (Guido van Rossum) Status: Draft Type: Standards Track Created: 11-Mar-2001 Python-Version: 2.2 Post-History: 16-Mar-2001, 26-Jul-2001, 27-Jul-2001 Abstract The current division (/) operator has an ambiguous meaning for numerical arguments: it returns the floor of the mathematical result of division if the arguments are ints or longs, but it returns a reasonable approximation of the division result if the arguments are floats or complex. This makes expressions expecting float or complex results error-prone when integers are not expected but possible as inputs. We propose to fix this by introducing different operators for different operations: x/y to return a reasonable approximation of the mathematical result of the division ("true division"), x//y to return the floor ("floor division"). We call the current, mixed meaning of x/y "classic division". Because of severe backwards compatibility issues, not to mention a major flamewar on c.l.py, we propose the following transitional measures (starting with Python 2.2): - Classic division will remain the default in the Python 2.x series; true division will be standard in Python 3.0. - The // operator will be available to request floor division unambiguously. - The future division statement, spelled "from __future__ import division", will change the / operator to mean true division throughout the module. - A command line option will enable run-time warnings for classic division applied to int or long arguments; another command line option will make true division the default. - The standard library will use the future division statement and the // operator when appropriate, so as to completely avoid classic division. Motivation The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as x*y**2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division. The problem is unique to dynamically typed languages: in a statically typed language like C, the inputs, typically function arguments, would be declared as double or float, and when a call passes an integer argument, it is converted to double or float at the time of the call. Python doesn't have argument type declarations, so integer arguments can easily find their way into an expression. The problem is particularly pernicious since ints are perfect substitutes for floats in all other circumstances: math.sqrt(2) returns the same value as math.sqrt(2.0), 3.14*100 and 3.14*100.0 return the same value, and so on. Thus, the author of a numerical routine may only use floating point numbers to test his code, and believe that it works correctly, and a user may accidentally pass in an integer input value and get incorrect results. Another way to look at this is that classic division makes it difficult to write polymorphic functions that work well with either float or int arguments; all other operators already do the right thing. No algorithm that works for both ints and floats has a need for truncating division in one case and true division in the other. The correct work-around is subtle: casting an argument to float() is wrong if it could be a complex number; adding 0.0 to an argument doesn't preserve the sign of the argument if it was minus zero. The only solution without either downside is multiplying an argument (typically the first) by 1.0. This leaves the value and sign unchanged for float and complex, and turns int and long into a float with the corresponding value. It is the opinion of the authors that this is a real design bug in Python, and that it should be fixed sooner rather than later. Assuming Python usage will continue to grow, the cost of leaving this bug in the language will eventually outweigh the cost of fixing old code -- there is an upper bound to the amount of code to be fixed, but the amount of code that might be affected by the bug in the future is unbounded. Another reason for this change is the desire to ultimately unify Python's numeric model. This is the subject of PEP 228[0] (which is currently incomplete). A unified numeric model removes most of the user's need to be aware of different numerical types. This is good for beginners, but also takes away concerns about different numeric behavior for advanced programmers. (Of course, it won't remove concerns about numerical stability and accuracy.) In a unified numeric model, the different types (int, long, float, complex, and possibly others, such as a new rational type) serve mostly as storage optimizations, and to some extent to indicate orthogonal properties such as inexactness or complexity. In a unified model, the integer 1 should be indistinguishable from the floating point number 1.0 (except for its inexactness), and both should behave the same in all numeric contexts. Clearly, in a unified numeric model, if a==b and c==d, a/c should equal b/d (taking some liberties due to rounding for inexact numbers), and since everybody agrees that 1.0/2.0 equals 0.5, 1/2 should also equal 0.5. Likewise, since 1//2 equals zero, 1.0//2.0 should also equal zero. Variations Aesthetically, x//y doesn't please everyone, and hence several variations have been proposed: x div y, or div(x, y), sometimes in combination with x mod y or mod(x, y) as an alternative spelling for x%y. We consider these solutions inferior, on the following grounds. - Using x div y would introduce a new keyword. Since div is a popular identifier, this would break a fair amount of existing code, unless the new keyword was only recognized under a future division statement. Since it is expected that the majority of code that needs to be converted is dividing integers, this would greatly increase the need for the future division statement. Even with a future statement, the general sentiment against adding new keywords unless absolutely necessary argues against this. - Using div(x, y) makes the conversion of old code much harder. Replacing x/y with x//y or x div y can be done with a simple query replace; in most cases the programmer can easily verify that a particular module only works with integers so all occurrences of x/y can be replaced. (The query replace is still needed to weed out slashes occurring in comments or string literals.) Replacing x/y with div(x, y) would require a much more intelligent tool, since the extent of the expressions to the left and right of the / must be analyzed before the placement of the "div(" and ")" part can be decided. Alternatives In order to reduce the amount of old code that needs to be converted, several alternative proposals have been put forth. Here is a brief discussion of each proposal (or category of proposals). If you know of an alternative that was discussed on c.l.py that isn't mentioned here, please mail the second author. - Let / keep its classic semantics; introduce // for true division. This still leaves a broken operator in the language, and invites to use the broken behavior. It also shuts off the road to a unified numeric model a la PEP 228[0]. - Let int division return a special "portmanteau" type that behaves as an integer in integer context, but like a float in a float context. The problem with this is that after a few operations, the int and the float value could be miles apart, it's unclear which value should be used in comparisons, and of course many contexts (like conversion to string) don't have a clear integer or float context. - Use a directive to use specific division semantics in a module, rather than a future statement. This retains classic division as a permanent wart in the language, requiring future generations of Python programmers to be aware of the problem and the remedies. - Use "from __past__ import division" to use classic division semantics in a module. This also retains the classic division as a permanent wart, or at least for a long time (eventually the past division statement could raise an ImportError). - Use a directive (or some other way) to specify the Python version for which a specific piece of code was developed. This requires future Python interpreters to be able to emulate *exactly* several previous versions of Python, and moreover to do so for multiple versions within the same interpreter. This is way too much work. A much simpler solution is to keep multiple interpreters installed. API Changes During the transitional phase, we have to support *three* division operators within the same program: classic division (for / in modules without a future division statement), true division (for / in modules with a future division statement), and floor division (for //). Each operator comes in two flavors: regular, and as an augmented assignment operator (/= or //=). The names associated with these variations are: - Overloaded operator methods: __div__(), __floordiv__(), __truediv__(); __idiv__(), __ifloordiv__(), __itruediv__(). - Abstract API C functions: PyNumber_Divide(), PyNumber_FloorDivide(), PyNumber_TrueDivide(); PyNumber_InPlaceDivide(), PyNumber_InPlaceFloorDivide(), PyNumber_InPlaceTrueDivide(). - Byte code opcodes: BINARY_DIVIDE, BINARY_FLOOR_DIVIDE, BINARY_TRUE_DIVIDE; INPLACE_DIVIDE, INPLACE_FLOOR_DIVIDE, INPLACE_TRUE_DIVIDE. - PyNumberMethod slots: nb_divide, nb_floor_divide, nb_true_divide, nb_inplace_divide, nb_inplace_floor_divide, nb_inplace_true_divide. The added PyNumberMethod slots require an additional flag in tp_flags; this flag will be named Py_TPFLAGS_HAVE_NEWDIVIDE and will be included in Py_TPFLAGS_DEFAULT. The true and floor division APIs will look for the corresponding slots and call that; when that slot is NULL, they will raise an exception. There is no fallback to the classic divide slot. In Python 3.0, the classic division semantics will be removed; the classic division APIs will become synonymous with true division. Command Line Option The -D command line option takes a string argument that can take three values: "old", "warn", or "new". The default is "old" in Python 2.2 but will change to "warn" in later 2.x versions. The "old" value means the classic division operator acts as described. The "warn" value means the classic division operator issues a warning (a DeprecationWarning using the standard warning framework) when applied to ints or longs. The "new" value changes the default globally so that the / operator is always interpreted as true division. The "new" option is only intended for use in certain educational environments, where true division is required, but asking the students to include the future division statement in all their code would be a problem. This option will not be supported in Python 3.0; Python 3.0 will always interpret / as true division. (Other names have been proposed, like -Dclassic, -Dclassic-warn, -Dtrue, or -Dold_division etc.; these seem more verbose to me without much advantage. After all the term classic division is not used in the language at all (only in the PEP), and the term true division is rarely used in the language -- only in __truediv__.) Semantics of Floor Division Floor division will be implemented in all the Python numeric types, and will have the semantics of a // b == floor(a/b) except that the result type will be the common type into which a and b are coerced before the operation. Specifically, if a and b are of the same type, a//b will be of that type too. If the inputs are of different types, they are first coerced to a common type using the same rules used for all other arithmetic operators. In particular, if a and b are both ints or longs, the result has the same type and value as for classic division on these types (including the case of mixed input types; int//long and long//int will both return a long). For floating point inputs, the result is a float. For example: 3.5//2.0 == 1.0 For complex numbers, // raises an exception, since float() of a complex number is not allowed. For user-defined classes and extension types, all semantics are up to the implementation of the class or type. Semantics of True Division True division for ints and longs will convert the arguments to float and then apply a float division. That is, even 2/1 will return a float (2.0), not an int. For floats and complex, it will be the same as classic division. Note that for long arguments, true division may lose information; this is in the nature of true division (as long as rationals are not in the language). Algorithms that consciously use longs should consider using //. If and when a rational type is added to Python (see PEP 239[2]), true division for ints and longs should probably return a rational. This avoids the problem with true division of longs losing information. But until then, for consistency, float is the only choice for true division. The Future Division Statement If "from __future__ import division" is present in a module, or if -Dnew is used, the / and /= operators are translated to true division opcodes; otherwise they are translated to classic division (until Python 3.0 comes along, where they are always translated to true division). The future division statement has no effect on the recognition or translation of // and //=. See PEP 236[4] for the general rules for future statements. (It has been proposed to use a longer phrase, like "true_division" or "modern_division". These don't seem to add much information.) Open Issues - It has been proposed to call // the quotient operator, and the / operator the ratio operator. I'm not sure about this -- for some people quotient is just a synonym for division, and ratio suggests rational numbers, which is wrong. I prefer the terminology to be slightly awkward if that avoids unambiguity. Also, for some folks "quotient" suggests truncation towards zero, not towards infinity as "floor division" says explicitly. - It has been argued that a command line option to change the default is evil. It can certainly be dangerous in the wrong hands: for example, it would be impossible to combine a 3rd party library package that requires -Dnew with another one that requires -Dold. But I believe that the VPython folks need a way to enable true division by default, and other educators might need the same. These usually have enough control over the library packages available in their environment. - For very large long integers, the definition of true division as returning a float causes problems, since the range of Python longs is much larger than that of Python floats. This problem will disappear if and when rational numbers are supported. In the interim, maybe the long-to-float conversion could be made to raise OverflowError if the long is out of range. FAQ Q. Why isn't true division called float division? A. Because I want to keep the door open to *possibly* introducing rationals and making 1/2 return a rational rather than a float. See PEP 239[2]. Q. Why is there a need for __truediv__ and __itruediv__? A. We don't want to make user-defined classes second-class citizens. Certainly not with the type/class unification going on. Q. How do I write code that works under the classic rules as well as under the new rules without using // or a future division statement? A. Use x*1.0/y for true division, divmod(x, y)[0] for int division. Especially the latter is best hidden inside a function. You may also write float(x)/y for true division if you are sure that you don't expect complex numbers. If you know your integers are never negative, you can use int(x/y) -- while the documentation of int() says that int() can round or truncate depending on the C implementation, we know of no C implementation that doesn't truncate, and we're going to change the spec for int() to promise truncation. Note that for negative ints, classic division (and floor division) round towards negative infinity, while int() rounds towards zero. Q. How do I specify the division semantics for input(), compile(), execfile(), eval() and exec? A. They inherit the choice from the invoking module. PEP 236[4] lists this as a partially resolved problem. Q. What about code compiled by the codeop module? A. Alas, this will always use the default semantics (set by the -D command line option). This is a general problem with the future statement; PEP 236[4] lists it as an unresolved problem. You could have your own clone of codeop.py that includes a future division statement, but that's not a general solution. Q. Will there be conversion tools or aids? A. Certainly, but these are outside the scope of the PEP. Q. Why is my question not answered here? A. Because we weren't aware of it. If it's been discussed on c.l.py and you believe the answer is of general interest, please notify the second author. (We don't have the time or inclination to answer every question sent in private email, hence the requirement that it be discussed on c.l.py first.) Implementation A very early implementation (not yet following the above spec, but supporting // and the future division statement) is available from the SourceForge patch manager[5]. References [0] PEP 228, Reworking Python's Numeric Model http://www.python.org/peps/pep-0228.html [1] PEP 237, Unifying Long Integers and Integers, Zadka, http://www.python.org/peps/pep-0237.html [2] PEP 239, Adding a Rational Type to Python, Zadka, http://www.python.org/peps/pep-0239.html [3] PEP 240, Adding a Rational Literal to Python, Zadka, http://www.python.org/peps/pep-0240.html [4] PEP 236, Back to the __future__, Peters, http://www.python.org/peps/pep-0236.html [5] Patch 443474, from __future__ import division http://sourceforge.net/tracker/index.php?func=detail&aid=443474&group_id=54… Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End:

1 0

[ANNOUNCE] M2Crypto 0.06
by Ng Pheng Siong July 26, 2001

July 26, 2001

Hi, I'm pleased to announce that M2Crypto 0.06 has been released. - M2Crypto now works with (and requires) SWIG 1.3.6. - ZServerSSL has been updated to work with Zope 2.4.0. - Beginnings of unit tests for M2Crypto.SSL. (Uses fork/exec, so presently Unix only.) Going forward, I'm aiming for the following: - SSL HOWTO - Better documentation - XML-dsig implementation - SRP implementation - More unit tests of everything Get M2Crypto here: http://www.post1.com/home/ngps/m2/ As usual, feedback is appreciated. -- Ng Pheng Siong <ngps(a)post1.com> * http://www.post1.com/home/ngps Quidquid latine dictum sit, altum viditur.

1 0

Python 2.1.1 for DJGPP alpha
by jon-sven＠frisurf.no July 25, 2001

July 25, 2001

This is a _VERY_ aplha release of Python 2.1.1 compiled with the DJGPP tools to provide binaries for 32-bit DOS systems. This is NOT to be considered a production quality release, and should only be used for testing. There are two packages available: - Python-2.1.1-djgppbin-alpha1.zip This is the compiled interpreter, libpython21.a and the module library. Simply unzip and adjust %PYTHONPATH% to install. - Python-2.1.1-djgppsrc-alpha1.zip These are the files needed to compile the original distribution. Unpack it on top of the existing source, and then $ make Do not ./configure, the archives comes with it's own config.h and Makefile. Building might require a sh-compatible shell, bash is available from ftp.simtel.net/pub/gnu/djgpp Go to http://jsven.hobbiton.org/djgpp/ to get the files Issues with this release: - os.name is currently 'posix'. This seems to work fairly well - It is statically linked, this means that all the C modules are builtin - There is no thread support - Quite a number of the tests in the testsuite are skipped because I didn't have the necessary libraries to build them available, a much higher level of completeness should be achievable. - I'm sure there are more, I'm tired. These are the testsuite results: 92 tests OK. 8 tests failed: test___all__ test_longexp test_popen2 test_socket test_sundry test_unicode test_zipfile test_zlib 35 tests skipped: test_al test_asynchat test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gc test_gdbm test_gl test_grp test_imgfile test_largefile test_linuxaudiodev test_locale test_minidom test_mmap test_nis test_openpty test_poll test_pty test_pwd test_pyexpat test_sax test_socketserver test_sunaudiodev test_thread test_threadedtempfile test_timing test_winreg test_winsound In addition to this, test_re, test_sre, test_select and test_signal had to be skipped manually because they crashed *violently*, this should be investigated in the future. I'll be grateful for any feedback. Jon Svendsen jsvendsen(a)bergen.frisurf.no

1 0

ANNOUNCE Mailman 2.0.6
by barry＠zope.com July 25, 2001

July 25, 2001

I've just released version 2.0.6 of Mailman, the GNU Mailing List Manager. Mailman is released under the GNU General Public License (GPL). Version 2.0.6 fixes a potential security problem in Mailman 2.0.x, and includes a few other minor bug fixes. It is possible, although unlikely, that you could have an empty site password, or an empty list password. Because of peculiarities in the Unix crypt() function, such empty passwords could allow unauthorized access to the list administrative pages with an arbitrary password string. This situation does not occur normally, but it is possible to create it by accident (e.g. by touch'ing data/adm.pw). This patch ensures that such empty passwords do not allow unauthorized access, by first checking to make sure that the salt is at least 2 characters in length. Alternatively, you can make sure that either data/adm.pw does not exist or that it is not empty. For the extra paranoid, you'd need to be sure that none of your lists have empty passwords, but that's an even more difficult situation to create by accident. This patch guards against both situations. (Please note that Mailman 2.1alpha is not vulnerable to this problem because it does not use crypt().) A few other minor bugs have been fixed; see the NEWS excerpt below for details. Mailman 2.0.6 is being released as both a gzip'd source tarball and as a patch file. GNU Mailman is software to help manage electronic mail discussion lists. Mailman gives each mailing list a unique web page and allows users to subscribe, unsubscribe, and change their account options over the web. Even the list manager can administer his or her list entirely via the web. Mailman has most of the features that people want in a mailing list management system, including built-in archiving, mail-to-news gateways, spam filters, bounce detection, digest delivery, and so on. Mailman is compatible with most web servers, web browsers, and mail servers. It runs on GNU/Linux and should run on any other Unix-like operating system. Mailman 2.0.6 requires Python 1.5.2 or newer. To install Mailman from source, you will need a C compiler. For more information on Mailman, including links to file downloads, please see the Mailman WWW page: http://www.gnu.org/software/mailman And its mirrors at: http://mailman.sourceforge.net http://www.list.org Downloads are available at http://sourceforge.net/project/shownotes.php?release_id=45268 There are email lists (managed by Mailman, of course!) for both Mailman users and developers. See the web sites above for details. Enjoy, -Barry 2.0.6 (25-Jul-2001) Security fix: - Fixed a potential security hole which could allow access to list administrative features by unauthorized users. If there is an empty data/adm.pw file (the site password file), then any password will be accepted as the list administrative password. This exploit is caused by a common "bug" in the crypt() function suffered by several Unix distributions, including at least GNU/Linux and Solaris. Given a salt string of length zero, crypt() always returns the empty string. In lieu of applying this patch, sites can run bin/mmsitepass and ensure that data/adm.pw is of length 2 or greater. Bug fixes: - Ensure that even if DEFAULT_URL is misconfigured in mm_cfg.py (i.e. is missing a trailing slash), it is always fixed upon list creation. - Check for administrivia holds before any other tests. - SF bugs fixed: 407666, 227694 - Other miscellaneous buglets fixed.

1 0

[Application] Threaded Stock Quote Retrieval
by Ron Boles July 25, 2001

July 25, 2001

Threaded Stock Quote Retrieval ------------------------------ Threaded application to download stock quotes from yahoo Apologies...being a python newbee, my code is naive. (we all have to start somewhere!) -name: getQuoteThread.py -Structure: threaded python application -GUI: wxPython -Input: ascii file. Line Format = "ticker,name" -Output: ascii file of quotes I would welcome any comments. Be as rude as you like! URL: ftp://catalog.net.au/python/getQuoteThread.py Download: ftp://catalog.net.au/python/getQuoteThread.py License: Open Source Gui: wxPython Categories: Net Applications Ron Boles (rjb(a)catalog.net.au) -- <a href="ftp://catalog.net.au/python/getQuoteThread.py">Threaded Stock Quote Retrieval</a> -- Threaded application to download stock quotes from yahoo

1 0

pyCGNS v0.1 - A Python binding to CGNS
by Marc Poinot July 23, 2001

July 23, 2001

This is a very specialized package for Computational Fluid Dynamics. The pyCGNS package is a proposal for a Python binding to the CGNS libraries. These libraries are dedicated to the management of a new Computational Fluid Dynamics database format. The package includes both a wrapper on top of the ADF libraries, and a wrapper on top of the SIDS (or CGNS) libraries. There is a set of tests, demos and a tree parse tool, all written using pyCGNS Python binding. You can also find a little intro doc: pyCGNS-v0.1/Doc/manual.ps This package requires the Numerical Python package. The package will be available on the anonymous ftp, at ONERA: ftp.onera.fr:/incoming/xtmp/pyCGNS/pyCGNS-v0.1.tar.gz It will be avaible for 4 days (sorry, automatic garbage there...) Send me an email if you want the package after this deadline. -MP- ----------------------------------------------------------------------- Marc POINOT Alias: marcvs Email: poinot(a)onera.fr ONERA -MFE/DSNA/ELSA Tel: 01.46.73.42.84 Info: elsa-info(a)onera.fr 29, Div. Leclerc Fax: 01.46.73.41.66 Site: 92322 Chatillon FRANCE Project: elsA Web: http://www.onera.fr

1 0