Mailman 3 November 2000 - Python-announce-list

python-dev summary: Oct. 17-31
by A.M. Kuchling Nov. 1, 2000

Nov. 1, 2000

Python-dev summary, October 17-31, 2000 ======================================= (To comment on material in this python-dev summary, you can simply post to comp.lang.python / <python-list(a)python.org>.) Pythoneers Move to Digital Creations ==================================== The most significant news in this two-week span was the five Pythoneers (GvR, Fred Drake, Jeremy Hylton, Tim Peters, Barry Warsaw) leaving BeOpen and being hired by Digital Creations. The terms of their hiring seem quite liberal. From GvR's announcement: "We will be spending part of our time on core Python development (including Jython and Mailman) and part of our time on Python infrastructure improvements that also benefit Zope." And, a few paragraphs later: "All future work we do on Python as Digital Creations employees will be owned by a non-profit organization yet to be created. We think of this new organization as the Python Software Foundation. In the meantime (while the PSF is under construction) I will own such copyrights personally." http://www.python.org/digicool.html No official statement from DC has been made as of this writing, though Paul Everitt has made some informal statements: "I'd like to start by saying that Guido and I have known each other a long time now. Barry too. We all really like each other, but we also know how to disagree constructively." http://weblogs.userland.com/zopeNewbies/discuss/msgReader$831 There was only a slight amount of paranoia triggered by the news. Some people wondered if DC would begin dictating Python's development, or start slanting the standard library toward Zope (discouraging enhancements to the Web development tools, for example). This scenario seems quite improbable. Instead, my crystal ball says it's more likely that certain language features and proposals will be given more of GvR's attention than they've previously gotten. For example, Jim Fulton, Zope's primary architect, has long been interested in ways to specify interfaces in Python: http://www.foretec.com/python/workshops/1998-11/dd-fulton-sum.html So interfaces may suddenly become a bit more interesting to Guido. Mending the class/type dichotomy would also be useful for Zope, and that means the odds of ExtensionClass or some equivalent functionality, being added to Python have probably just increased. (See "Other Matters", below, for an example. ) But I do expect Guido will keep calling the shots as to exactly how any such new features fit into the language. Whither Tk? =========== It was an eventful two weeks for scripting languages in general, really. On October 20th that a company called Interwoven announced that it will be acquiring Ajuba Solutions, formerly known as Scriptics. Scriptics was the company founded by John Ousterhout to provide support for the Tcl scripting language and the Tk GUI toolkit. However, Interwoven isn't interested in Tcl/Tk at all and will not be funding its development. Ajuba knew this was coming, of course, and over the past few months efforts have been made to open up Tcl/Tk development to the community, taking such steps as moving the CVS trees to SourceForge, electing a Tcl Core Team with 14 members, and specifying processes for proposing and voting on core changes (the Tcl equivalent of PEPs). http://dev.scriptics.com/community/coreteam/ http://sourceforge.net/projects/tcl http://sourceforge.net/projects/tktoolkit However, this process is still in its infancy, and the announcement caused much worrying in the Tcl/Tk user community about the language's future and its continued maintenance. This affects Python because Tk, through the Tkinter module, is the most GUI most commonly used with Python. Tkinter is included in the source distribution, it's the most extensively documented, and it's the most portable, supported on the Big Three platforms, namely Windows, Unix, and MacOS. Fredrik Lundh first posted a note about the announcement, and Eric S. Raymond raised the question of what this meant for Tkinter: "This raises anew a question I've been meaning to bring up for the last week: is it finally time to move away from Python's dependence on Tcl/Tk for GUI support?" http://www.python.org/pipermail/python-dev/2000-October/016753.html People were split on this question, though Guido was receptive to the idea ("Yes, it may be time to have this discussion again.") and pointed out some reasons to stick with Tkinter: "Tk has two very high quality widgets: the Canvas and Text widgets are unsurpassed in functionality and robustness by other widget sets. You can draw more lines or characters per second in most toolkits, but few toolkits offer the convenience of marks and tags, not having to deal with refresh events, being able to group objects, move them around, change attributes, etc., etc., etc." http://www.python.org/pipermail/python-dev/2000-October/016754.html Greg Wilson's reaction was "Yes please", and he went on to explain what factors kept him using Tkinter for a recent course: http://www.python.org/pipermail/python-dev/2000-October/016757.html /F thought Tk was still a good choice, and said " ... and trust me, the Python 2.0/Tk8.4/Tkinter3000 combo will rock ;-)". Tkinter3000 is an improved Tk interface that /F has been working on, with more flexibility and better performance. http://tkinter.effbot.org /F also hoped that the Tcl Core Team would become more receptive to making it easier to use Tk from other languages without Tcl having to be in the middle, which would let the maintainers of Tkinter and the Perl/Tk interface participate more in Tk's development. Eric S. Raymond speculated about the success of Tcl's new development model: "Good for Tcl: Osterhout's rather lame attempts to develop under a mixed model have almost certainly come to an end in favor of an Apache-like model funded by big Tcl users." http://www.python.org/pipermail/python-dev/2000-October/016763.html Greg Ewing wondered if stdwin should be revived. GvR and Raymond both thought that far too much work, and not productive of very good results. "And stdwin would really look pathetic in this time", GvR observed. Python isn't tied very tightly to Tk, of course; well-maintained and reasonably complete bindings exist for many different GUI toolkits, such as Qt, GTk+, wxWindows, Windows MFC, and a few more. http://www.thekompany.com/projects/pykde/ http://www.daa.com.au/~james/pygtk/ http://wxpython.org/ http://http://www.oreillynet.com/pub/a/217 wxWindows is probably the most obvious second candidate, since it actually supports all of the Big Three platforms, and no other toolkit does. Robin Dunn, author of the wxPython binding, posted to discuss the status of wxWindows on the Mac: "My understanding is that the version in CVS is nearly up to date with the features in the MSW and GTK versions, though I haven't had a chance to use it myself. ... The next step I guess is getting it wrapped up in wxPython..." http://www.python.org/pipermail/python-dev/2000-October/016764.html There was no clear final decision, and my crystal ball didn't deign to give an answer. Given all the uncertainties, it's probably best to wait and see. If Tk's development continues to progress and becomes more open to languages other than Tcl, Tkinter will probably continue to be the most common Python GUI. If not, we can consider this question in another 6 months, which will give wxWindows and wxPython time to develop on the Mac platform. And who knows? Maybe something else will happen, such as Qt or GTk+ being ported to the Macintosh. Gradual Migration ================= Paul Prescod suggested that we should start thinking about how to make the transition to the vaporware Python 3000 easier: "Rather than delaying painful backwards-compatibility breakage I think we should make it less painful. We should decide where we are going long before we ask our users to move there. I think we should start including alternatives to syntaxes and features that we know are broken. Once people move to the alternatives we can 'reassign' or remove the original syntax with much less pain." http://www.python.org/pipermail/python-dev/2000-October/016776.html Reaction was enthusiastic, GvR commenting: "I think the proper approach is to start a separate migration process for each of these proposed changes. Each should be paced separately (the pace may depend on how hard to swallow the change is for users as well as how hard it is to implement the new functionality) and for each, a separate PEP in the 3000 series should be started." http://www.python.org/pipermail/python-dev/2000-October/016780.html Paul got approval to write PEP #5: "Guidelines for Language Evolution". http://python.sourceforge.net/peps/pep-0005.html Along the way, Tim Peters commented: "Not just to be my usual self <wink>, but I do see a from-scratch rewrite as being less likely as the years go by. There's nothing I know of in Guido's plans that can't be done incrementally instead -- and if he doesn't either, selling a total-rewrite project to an employer is probably impossible. The most successful projects I've seen and been on *did* rewrite all the code routinely, but one subsystem at a time." http://www.python.org/pipermail/python-dev/2000-October/016819.html Other matters ============= Neil Schemenauer posted a proposal for a core change that would make ExtensionClass better able to simulate a Python instance: "Extension classes can never pass the PyInstance_Check predicate. I've searched for all occurances of PyInstance_Check in the 2.0 source. In many places that PyInstance_Check occurs a more general 'is this an instance-like type' check would seem to be more suitable." http://www.python.org/pipermail/python-dev/2000-October/016797.html Guido thought this simply papers over the problem in this one particular case, and said "Rather than formalizing the exceptions made for instances, we should work on eradicating the differences between classes and types. I believe that the plans for rich comparisons would or could also take care of this. I hope I'll have more time soon to explore this." Jim Fulton, in a brief followup, said "Me too." Barry Warsaw proposed adding a function to the sys module which would return the stack frame for getting the stack frame of the function's caller: http://www.python.org/pipermail/python-dev/2000-October/016802.html People liked the idea; M.-A. Lemburg, Greg Ward, and Ka-Ping Yee all had their own implementations of this function already. ?!ng reminded the list of his inspect.py module which provides this function, and other functions for inspecting live Python code, and suggested it for inclusion in the standard library: http://lfw.org/python/inspect.py No resolution was arrived at. Related Links ============= Python-dev archives: http://www.python.org/pipermail/python-dev/ Python project page on SourceForge: http://sourceforge.net/projects/python Python Enhancement Proposals (PEPs): http://python.sourceforge.net/peps/ What's New in Python 2.0: http://www.kuchling.com/python/writing/new-python/

1 0

[ANN] MoinMoin Release 0.4
by J�rgen Hermann Nov. 1, 2000

Nov. 1, 2000

A WikiWikiWeb is a collaborative hypertext environment, with an emphasis on easy access to and modification of information. MoinMoin is a Python WikiClone that allows you to easily set up your own wiki, only requiring a Web server and a Python installation. Sorry for the short release cycle, but I've been a busy bee and added some major new features: table markup, section headlines, some new macros, and finally a set of help pages describing all current features. This is the last release of MoinMoin before major refactoring takes place. So don't expect a new one within at least a month. Homepage: http://moin.sourceforge.net/ Download: http://download.sourceforge.net/moin/ New features: * Table markup "||a||b||c||" * Headlines "= H1 =", "== H2 ==", and so on up to H5 * [[PageCount]] macro * Added [[Icon(image)]] macro and macro arguments * [[PageList(title-regex)]] macro * New help system (set of help pages describing all features) Bugfixes: * Create complete URL for "Clear message" link * Inline code spans needed cgi.escape * Better fix for Python 1.6 "re" problems * Fix for uppercase extensions in inline images ("foo.JPG") * Fixed colspan in RecentChanges * HR size is now limited to 8 * "}" ends an URL pattern (fixes URLs right at the end of code displays)

1 0

ANN: mx Extension Series for Python 2.0
by M.-A. Lemburg Nov. 1, 2000

Nov. 1, 2000

________________________________________________________________________ ANNOUNCING: mx Extension Series for Python 2.0 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The mx Extension Series is a collection of Python software packages which aims at providing professional quality add-ons for the Open Source Language Python (see http://www.python.org). All of the available packages are proven in every day use and fullfil mission critical jobs in various commercial settings all around the world. The two most well-known packages from the mx Extension Series are mxDateTime and mxODBC providing date/time services and professional ODBC database connectivity on practically all supported Python platforms. These two packages enable database software which is portable not only across platforms, but also across database backends. ________________________________________________________________________ WHAT'S NEW ? The new download archives now all include binaries for Windows platforms which were compiled against Python 2.0. This means that installing the extensions on Windows boils down to unzipping the archives into C:\Python20\Lib. Versions for Python 1.5.2 are still available too. More packages and updated versions of the existing packages will be published in the first quarter 2001. All mx Extension Series packages will then move under a new top-level package named "mx". ________________________________________________________________________ PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxODBC - Generic ODBC 2.0 interface mxODBC is an extension package that provides a Python Database API compliant interface to ODBC 2.0 capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). The latest version of the interface allows you to interface to more than one database from one process. It includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid and many more. A precompiled version of the extension for use with the Windows ODBC manager is also included. mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxCrypto - Interface to Eric Young's SSLeay/OpenSSL mxCrypto is an extension package that provides OO-style access to the cipher algorithms and hash functions included in SSLeay, a very nifty cryptographic lib written by Eric Young now maintained by the OpenSSL team. Apart from being usable stand-alone, it provides hooks that make it work as high quality fill-in for the missing parts in Andrew Kuchling's pycrypt export package. Due to the ITAR export restrictions on cryptographic software Andrew's implementations are not legally downloadable from outside the US. SSLeay/OpenSSL is available world-wide. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. ________________________________________________________________________ WHERE CAN I GET IT ? The download archives, full documentation and instructions for installing the packages can be found at: http://starship.python.net/~lemburg/mxExtensions.html ________________________________________________________________________ WHAT DOES IT COST ? Most packages come with a Python-style license, which means that you can use them in both commercial and non-commercial settings without fee or charge. All packages come with full source code. mxODBC comes with a license comparable to the old MySQL license: it is only free for in-house use. If you use it in consulting work or otherwise redistribute it in a commercial setting, you will have to get a commercial license. More information about mxODBC licensing is available at: http://starship.python.net/~lemburg/mxODBC-License.html The next version of mxODBC will be made available as shareware in order to support further development of the software (including full Unicode support, support for ODBC 3.5 data types and special hooks for vendor specific ODBC extensions such as binding to files). ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial support for these packages will be available from eGenix.com Software starting in January 2001. If you'd like more information about this service, contact the eGenix.com helpdesk at info(a)egenix.com . ________________________________________________________________________ REFERENCE: <P><A HREF="http://starship.python.net/~lemburg/mxExtensions.html>mx Extension Series</A> - mx Extension Series with support for Python 2.0. (01-Nov-2000) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

ANN: mx Extension Series for Python 2.0
by M.-A. Lemburg Nov. 1, 2000

Nov. 1, 2000

________________________________________________________________________ ANNOUNCING: mx Extension Series for Python 2.0 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The mx Extension Series is a collection of Python software packages which aims at providing professional quality add-ons for the Open Source Language Python (see http://www.python.org). All of the available packages are proven in every day use and fullfil mission critical jobs in various commercial settings all around the world. The two most well-known packages from the mx Extension Series are mxDateTime and mxODBC providing date/time services and professional ODBC database connectivity on practically all supported Python platforms. These two packages enable database software which is portable not only across platforms, but also across database backends. ________________________________________________________________________ WHAT'S NEW ? The new download archives now all include binaries for Windows platforms which were compiled against Python 2.0. This means that installing the extensions on Windows boils down to unzipping the archives into C:\Python20\Lib. Versions for Python 1.5.2 are still available too. More packages and updated versions of the existing packages will be published in the first quarter 2001. All mx Extension Series packages will then move under a new top-level package named "mx". ________________________________________________________________________ PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxODBC - Generic ODBC 2.0 interface mxODBC is an extension package that provides a Python Database API compliant interface to ODBC 2.0 capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). The latest version of the interface allows you to interface to more than one database from one process. It includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid and many more. A precompiled version of the extension for use with the Windows ODBC manager is also included. mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxCrypto - Interface to Eric Young's SSLeay/OpenSSL mxCrypto is an extension package that provides OO-style access to the cipher algorithms and hash functions included in SSLeay, a very nifty cryptographic lib written by Eric Young now maintained by the OpenSSL team. Apart from being usable stand-alone, it provides hooks that make it work as high quality fill-in for the missing parts in Andrew Kuchling's pycrypt export package. Due to the ITAR export restrictions on cryptographic software Andrew's implementations are not legally downloadable from outside the US. SSLeay/OpenSSL is available world-wide. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. ________________________________________________________________________ WHERE CAN I GET IT ? The download archives, full documentation and instructions for installing the packages can be found at: http://starship.python.net/~lemburg/mxExtensions.html ________________________________________________________________________ WHAT DOES IT COST ? Most packages come with a Python-style license, which means that you can use them in both commercial and non-commercial settings without fee or charge. All packages come with full source code. mxODBC comes with a license comparable to the old MySQL license: it is only free for in-house use. If you use it in consulting work or otherwise redistribute it in a commercial setting, you will have to get a commercial license. More information about mxODBC licensing is available at: http://starship.python.net/~lemburg/mxODBC-License.html The next version of mxODBC will be made available as shareware in order to support further development of the software (including full Unicode support, support for ODBC 3.5 data types and special hooks for vendor specific ODBC extensions such as binding to files). ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial support for these packages will be available from eGenix.com Software starting in January 2001. If you'd like more information about this service, contact the eGenix.com helpdesk at info(a)egenix.com . ________________________________________________________________________ REFERENCE: <P><A HREF="http://starship.python.net/~lemburg/mxExtensions.html> mx Extension Series for Python 2.0</A> - mx Extension Series for Python 2.0. (01-Nov-2000) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Nov 1)
by Grant Edwards Nov. 1, 2000

Nov. 1, 2000

Guido van Rossum: PythonLabs Team Moves to Digital Creations http://deja.com/=dnc/getdoc.xp?AN=686714305 Randy Hudson nicely illustrate the event-listener pattern in the context of Jython as an extension language for Java http://deja.com/=dnc/getdoc.xp?AN=688152500 Moshe Zadka shows a portable locking mechanism http://deja.com/=dnc/getdoc.xp?AN=687180692 Thomas Wouters provides a pointer to another locking scheme http://deja.com/=dnc/getdoc.xp?AN=687318753 A.M. Kuchling reviews _Teach_Yourself_Python_in_24_Hours_ http://deja.com/=dnc/getdoc.xp?AN=687798879 Alex Martelli explains why slice indices work the way they do http://deja.com/=dnc/getdoc.xp?AN=688046177 and builds a primitive "use strict" before a live audience http://deja.com/=dnc/getdoc.xp?AN=687764895 then re-does it metaprogrammatically http://deja.com/=dnc/getdoc.xp?AN=687700793 ======================================================================== Everything you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org although PythonLabs.com bills itself as "The Python Source", which is becoming increasingly true in 2000 http://www.pythonlabs.com/ PythonWare complements the digest you're reading with the daily python url http://www.pythonware.com/daily comp.lang.python.announce announces new Python software. Be sure to scan this newly-revitalized newsgroup at least weekly. http://deja.com/group/comp.lang.python.announce Andrew Kuchling writes marvelous summaries twice a month of the action on the python-dev mailing list, where the future of Python is truly determined http://www.kuchling.com/python/dev/ The Vaults of Parnassus ambitiously collects Python resources http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Consortium emerges as an independent nexus of activity http://www.python.org/consortium Cetus does much of the same http://www.cetus-links.de/oo_python.html Python FAQTS http://python.faqts.com/ Python To-Do List anticipates some of Python's future direction http://www.python.org/cgi-bin/todo.py Python Journal is at work on its second issue http://www.pythonjournal.com Links2Go is a new semi-automated link collection; it's impressive what AI can generate http://www.links2go.com/search?search=python Archive probing trick of the trade: http://www.dejanews.com/dnquery.xp?QRY=&DBS=2&ST=PS&defaultOp=AND&LNG=ALL&f… Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://purl.org/thecliff/python/url.html or http://www.dejanews.com/dnquery.xp?QRY=~g%20comp.lang.python%20Python-URL%21 Suggestions/corrections for next week's posting are always welcome. [http://www.egroups.com/list/python-url-leads/ is hibernating. Just e-mail us ideas directly.] To receive a new issue of this posting in e-mail each Monday morning, ask <claird(a)neosoft.com> to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project. -- Cameron Laird <claird(a)NeoSoft.com> Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html

1 0

[FAQTS] Python Knowledge Base Update -- November 1st, 2000
by Fiona Czuczman Nov. 1, 2000

Nov. 1, 2000

Greetings, The latest entries into http://python.faqts.com regards, Fiona ## Edited Entries ############################################## ------------------------------------------------------------- Where can I best learn how to parse out both HTML and Javascript tags to extract text from a page? http://www.faqts.com/knowledge-base/view.phtml/aid/3680 ------------------------------------------------------------- Paul Allopenna, Matthew Schinckel, Magnus Lyckå Python Documentation If you want to (quickly) strip all HTML tags from a string of data, try using the re module: import re file = open(filename,'r') data = file.read() file.close() text = re.sub('', '', data) #Remove comments first, or '>' in #comments will be interpreted as #end of (comment) tag. text = re.sub('<.*?>', '', text) This will also strip any javascript, but only if the page has been made 'properly' - that is, the javascript is within HTML comments. If you want to know how it works, read the 're' chapter in the library reference, as it discusses the usefulness of 'non-greedy' regular expressions. ------------------------------------------------------------- How do I check and retrieve the error conditions & message of script executed via the Python/C API (without using PyErr_Print) http://www.faqts.com/knowledge-base/view.phtml/aid/6234 ------------------------------------------------------------- Kostas Karanikolas, Fiona Czuczman Alex Martelli See Section 4, "Exception Handling", in the Python/C API Reference Manual. PyErr_Occurred() returns a borrowed- reference pointer to the latext exception-type PyObject if any is pending, NULL if no error is pending; to check whether the exception is one you want to handle, pass this non-NULL pointer as the first argument to function PyErr_GivenExceptionMatches, second argument being the exception-type or class you want to handle -- it will return non-0 if matching. For finer control, you can call PyErr_Fetch, with three PyObject** arguments, for type, value, and traceback objects -- if no error is pending, each pointed-to pointer will be set to 0; else, at least the first (to type-object) will be non-0 (a reference will have be added to objects returned in this way). What you mean by "message" is probably what you get by PyObject_Str on the value object pointer (if non-0). ------------------------------------------------------------- I'm getting an error stating that "None" object has no attribute "groups" during setup of numpy, any ideas? http://www.faqts.com/knowledge-base/view.phtml/aid/6245 ------------------------------------------------------------- Michael Risser, Nicholas Hendley Oleg Broytmann It seems you are trying to do the following - match or search for regular expression: match_object = re.search(pattern, string) groups = match_object.groups() But your regexp didn't match anything in the string, so match_object here is really None. Test it before doing anything with it: match_object = re.search(pattern, string) if match_object: groups = match_object.groups() else: print "No match!" ------------------------------------------------------------- How do you access the printer from Python under Linux??? http://www.faqts.com/knowledge-base/view.phtml/aid/6376 ------------------------------------------------------------- Dave Berry, Donovan Baarda This question is very open. There are three main levels at which you can access the printer under linux; user, device, and IO port. The usual user level access is to print documents using the 'lpr' command. This will spool documents for printing in /var/spool/lpr to be printed in order when the printer is available, and allows multiple users to print documents without causing conflicts. This requires that the Linux box has lpd configured and running. Typicaly lpd is configured to use something like magic-filter to automaticly convert different types of documents into the format understood by the printer. This means most standard file types (postscript, png, text, etc) can be printed directly. (Note that there are alternatives to lpd, such as cups, that perform basicly the same thing). From Python, things can be printed as follows; import os filename='~/file.ps' os.system('lpr %s' % filename) or p=os.popen('lpr','w') p.write('printing test text string\n') p.close() Device level access involves directly opening the linux device file and writing to it. This requires that the user has write level access to the device, and does not allow shared access to the printer. This is not normaly what you want to do unless you are writing something like your own lpd replacement. Guru's might be able to do some ioctl magic on the device to do things like get the printer status, but otherwise this is pretty simple; p=os.open('/dev/lp1','w') p.write('printing text test string\n') p.close() IO port level access is the lowest level. You do not want to do this unless you really want to do wierd things with your printer port. An example of this might be plugging in some strange home-built hardware. There are a few ways to do this, but the easiest is using the linux '/dev/port' device that allows direct access to IO ports. The user must have write access to this device. WARNING!!! making a mistake when accessing '/dev/port' can seriously stuff up your system! You must know exactly what you are doing when you use this device. I probably shouldn't be writing this, because if you know enough to try this, you probably already know how :-) IOports=open("/dev/port","r+b",0) def GetChar(address): IOports.seek(address) return ord(IOports.read(1)) def PutChar(address,c): IOports.seek(address) IOports.write(chr(c)) class lpt: def __init__(self,port=0x378): self.address=port def Put_Data(self,c): PutChar(self.address,c) def Get_Data(self): return GetChar(self.address) def Put_Status(self,c): PutChar(self.address+1,c) def Get_Status(self): return GetChar(self.address+1) def Put_Control(self,c): PutChar(self.address+2,c) def Get_Control(self): return GetChar(self.address+2) p=lpt() p.Put_Data('a') c=p.Get_Status() IOPorts.close() ------------------------------------------------------------- How do you keep track of elements of "ravel"ed Numeric arrays http://www.faqts.com/knowledge-base/view.phtml/aid/4286 ------------------------------------------------------------- Nathan Wallace, Fiona Czuczman, Rob Hooft Hans Nowak, Snippet 93, Alex """ Packages: maths.numeric """ """ Hi, again. In case anyone else needs to do something like sorting an array and keeping track of what belongs where in the array, I've found the following function useful. It's not super-fast, but I guess it's doing a lot. """ import operator from Numeric import * def flatten_indices (array): index_array = indices (array.shape) index_list = map (ravel, tuple (index_array)) index_list = apply (map, (None, ) + tuple (index_list)) values = map (operator.getitem, \ len (index_list) * [array], \ index_list) return map (None, values, index_list) """ E.g. >>> b = reshape (arange (4), (2, 2)) >>> flatten_indices (b) [(0, (0, 0)), (1, (0, 1)), (2, (1, 0)), (3, (1, 1))] >>> """

1 0