MacPython 2.0beta1 has been released. You can download it through the
MacPython homepage, http://www.cwi.nl/~jack/macpython.html .
Aside from all the goodies that are not mac-specific there's quite a
bit of new mac-only stuff too. Here's the release notes:
Changes in 2.0b1 since 1.5.2
----------------------------
These release notes refer to Mac-specific changes only. See NEWS (in the Misc folder)
for machine-independent changes.
Unfortunately I have messed my administration up, so I can't give complete
Mac-specific release notes for the changes in this release. So, I will
have to leave it at the highlights:
- 68K support has been dropped, this release is PPC only.
- Threads support (through standard Python threads module).
- Tkinter works again! At least: it doesn't immedeately crash in obvious ways.
- Appearance support through App module and added calls in many other modules.
Most dialogs and applets have also been converted to Appearance. There's also a
ControlAccessor module that handles [GS]etControlData with their plethora of
argument types.
- Navigation Services support, with macfs StandardFile calls transparently
replaced by their NavServices counterparts.
- Offscreen QuickDraw and GWorld support through Qdoffs module.
- Drag manager support (Drag module).
- Much better CGI support and examples, see :Mac:Tools:CGI.
- Better OSA/AppleEvent support.
- Up/downcasting of handle-based types is now unified and implemented in the
inherting module, e.g.
handleobj = ctlobj.as_Resource()
ctlobj = Ctl.as_Control(handle)
- Added macos.FreeMem(), MaxBlock() and CompactMem(), mainly so apps in Python can
give low-memory warnings.
- MediaDescr module parses some QuickTime media descriptions (but definitely not all).
What is not in this distribution
--------------------------------
- The garbage collection mods to 2.0 have not been enabled, mainly due to lack of test-time.
- Stackless Python/microthreads are not in here. Ask on the pythonmac-SIG if you want them.
- Carbon support is not in here, but should be happening as soon as GUSI is ready.
- Distutils is not in here, again due to lack of time.
Known problems
--------------
This list is far from complete, more problems may be listed on the MacPython homepage,
http://www.cwi.nl/~jack/macpython.html.
- The IDE and Tkinter do not work together. Run tkinter programs under PythonInterpreter.
- Aliases do not work in sys.path entries.
--
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/ ++++
Announcing HappyDoc, a Python documentation extraction tool.
HappyDoc is a tool for extracting documentation from Python source
code. It differs from other such applications by the fact that it
uses the parse tree for a module to derive the information used in
its output, rather that importing the module directly. This allows
the user to generate documentation for modules which need special
context to be imported.
Version 0.7.1
Version 0.7.1 contains several fixes for reported bugs. Special
thanks to Jesper Hertel and many others for reporting them so
quickly and clearly.
With this update, I have also updated the Zope source documentation
files on Zope.org at http://www.zope.org/Members/hellmann/ZopeSrcDocs.
Download
Download the latest version of HappyDoc from the home page on
SourceForge:
http://sourceforge.net/projects/happydoc
Doc-string Format
How does an author write documentation so that it will be marked up
and look fancy? This is a perennial question for Python, and seems
to have introduced a roadblock into the development of more robust
and useful documentation tools. By separating the formatter classes
from the docset classes, HappyDoc allows a user to create their own
formatter to interpret comments in any way they see fit.
The default for the HTMLTableFormatter (the default formatter for
HappyDoc) is to treat __doc__ strings as StructuredText. Don't like
StructuredText? Write your own formatter that does something
different and drop it into place.
Documentation not in Doc-strings
It is not always desirable to put all documentation in __doc__
strings. Sometime, notably when working with Zope, special meaning
is attached to the presence of __doc__ strings. For this reason,
and to support existing code which might not have __doc__ strings,
HappyDoc will find and extract documentation in Python comments.
Comment documentation can contain all of the same formatting as
__doc__ strings. The preceding comment marker will be stripped off
and the lines will be assembled and treated as a block of
StructuredText.
To use this feature, it is important to place the comments
**before** the named object which they describe. In this example:
#
# Class documentation goes here
#
class ClassWithNoDocStrings:
"Using __doc__ strings overrides comment documentation."
def method1(self, params):
"This method uses a __doc__ string."
pass
#
# Method2 does not use a __doc__ string.
#
def method2(self):
pass
The output would include the __doc__ strings for the class and for
method1. It would also make it appear that method2 had a __doc__
string with the contents "Method2 does not use a __doc__ string."
I'm very pleased to announce ScanErrLog 1.4
ScanErrLog is a python module which extracts error messages from Apache
error_log files and present them in decreasing order of number of
occurences, with lots of options.
This is especially useful if you're interested in knowing the error
messages which annoy the most your website's visitors.
You can use it either as a standalone program or import it into another
python program, or use it as a CGI script.
You can produce reports in HTML, XML, PDF or plain TEXT format
You can:
- view sample reports
- test it online with real data
- download it
from: http://cortex.unice.fr/~jerome/scanerrlog/
The 1.4 release includes important bug fixes.
Any feedback is very welcome.
PS: PDF support needs you to install the Excellent ReportLab
(http://www.reportlab.com)
--
Jerome ALET - alet(a)unice.fr - http://cortex.unice.fr/~jerome
[Resending to debug the moderation setup]
A unique event in all the history of Python: two releases on the same
day! (At least in my timezone. :-)
Python 2.0b1 is released. The BeOpen PythonLabs and our cast of
SourceForge volunteers have been working on this version on which
since May. Please go here to pick it up:
http://www.pythonlabs.com/tech/python2.0/
There's a tarball and a Windows installer, online documentation (with
a new color scheme :-), RPMs, and a long list of new features. OK, a
teaser:
- Augmented assignment, e.g. x += 1
- List comprehensions, e.g. [x**2 for x in range(10)]
- Extended import statement, e.g. import Module as Name
- Extended print statement, e.g. print >> file, "Hello"
- Optional collection of cyclical garbage
There's one bit of sad news: according to Richard Stallman, this
version is no more compatible with the GPL than version 1.6 that was
released this morning by CNRI, because of a technicality concerning
the choice of law provision in the CNRI license. Because 2.0b1 has to
be considered a derivative work of 1.6, this technicality in the CNRI
license applies to 2.0 too (and to any other derivative works of 1.6).
CNRI is still trying to work this out with Stallman, so I hope that we
will be able to release future versions of Python under a
GPL-compatible license.
There's Only One Way To Do It.
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
I'm happy to announce beta release of Wing IDE, a commercial integrated
development environment for Python. The beta release runs on Linux and
requires a Python 1.5.2 interpreter; A Windows 9*/NT/2K version and
support for the 2.0 interpreter will be available subsequently.
Wing IDE may be obtained, along with a free 30-day evaluation license,
from www.wingide.com.
Features include:
* Graphical debugger with the ability to debug remote processes, such
as web CGIs. The core of the debugger is implemented in C, making it
much faster than the standard pdb module.
* Powerful source code editor, including syntax highlighting,
auto-completion, auto-indentation, source structure menu, multi-part
key
bindings, keyboard/command macros, and an emacs personality.
* Module- and class-oriented code browsing based on continually updated
analysis of source code.
A single user license for Wing IDE costs $99 US. At our discretion, we
offer discounts for students, volume purchases, and non-commercial open
source developers.
We hope you'll take a test flight today, and look forward to your
feedback
on how Wing IDE can be improved!
Thanks,
John Ehresman
------------------------------------------------------------------------
Archaeopteryx Software, Inc. Wing IDE for Python
www.archaeopteryx.com Take Flight!
Merely 4 hours past the deadline, the Zope Weekly News
lands with a heaping helping of goodies: Rapid
Zope Book evolution, lots of fish in the bowl,
Zope skin, PTK proliferation, and Zope.org replication.
The opinions expressed in Zope Weekly news are solely the authors',
and not the opinions of Digital Creations, The Zope Community
at-large, or the Spanish Inquisition.
You can always get to the most recent Zope Weekly News
with "one convenient URL",
http://www.zope.org/Documentation/ZWN/current
And Now For Something Completely Different:
---
Documentation
-- by Michel Pelletier
This week (a shorty due to Labor day) Amos and I are polishing up
spelling, added image and figure semantics to structured text (and
extended the HTML and SGML generators to spit them out, yum!).
Normalized all the font and style conventions, and started on chapter
1 screenshots. Yeah! I fleshed out a lot of Chapter 9 (Cataloging)
also. As always, you can "see the latest and greatest version",
http://www.zope.org/Members/michel/ZB/
---
Zope Status
-- by Brian Lloyd
Summary
Zope 2.2.1 release, progress on dev.zope.org projects
Recent highlights
ZWN has been spotty lately so to recap, Zope 2.2.1 was released
August 25th. Lots and lots of bugs were fixed for 2.2.1, and it
seems to have covered the issues that were keeping people from
moving to 2.2. There have been two reported problems with custom
ZClasses after updating to 2.2.1, but we have not been able to
reproduce them and they do not seem to be a general problem.
There has been a fair amount of activity on dev.zope.org, with
a number of new proposals for things such as session tracking
and a unit testing support framework. Chris McDonough gets the
prolific-proposal-writer-of-the-week award :) The new security
assertion proposal has been made into an active project, and
the first draft of the first deliverable (the Zope developer's
guide to product security) is "available for review and feedback",
http://dev.zope.org/Wikis/DevSite/Projects/DeclarativeSecurity/ZopeSecurity…
There are also a number of proposal where discussion seems to have
petered out - we'll need to start looking at these over time and
decide how to either get champions to refine them and move them
forward or put them in some sort of proposal archive.
In other news, FourThought continues to work on the new
XMLDocument and will shortly be starting on the XSL Templates
project.
This week
This week we will be starting to firm up a todo list for the next
Zope feature release and trying to get the declarative security
"user manual" finalized - after that we'll begin implementing the
new assertion style for the next feature release.
---
Zope Studio
-- by Martijn Pieters
Zope Studio
Due to other project work, no news this week
Skinnable And Localizable Objects
After two weeks of holidaying in Scotland, I am back at the keys.
Week of 13-08
- Architecture finalised.
- Implemented all core objects and code.
- Made practically all of Zope Skinnable
This Week
- Add some code to make skinned files in Zope Core more backward
compatible.
- Clean up last few objects with recalcitrant, inline DTML, and make
then Skinnable.
- Split out all strings to make Zope fully translatable.
---
State of the PTK, 2000/09/04
In the weeks since our last report, the PTK community has been
quite busy:
* Shane Hathaway landed the proposed "next-generation architecture",
http://www.zope.org/Products/PTK/ZWiki/NewPTKArchitecture,
refactoring the "toolkit" as a set of "portal tools", each
providing services to other objects in the portal. The tools
include:
'portal_membership' -- tracks personalization and owned content,
tying them (much more loosely) to the AUTHENTICATED_USER.
'portal_registration' -- implements portal-specific policies for
user
signup, password generation/mailng, etc.
'portal_workflow' -- encapsulates the workflow policies of the
portal
'portal_catalog' -- indexes portal content
'portal_discussions' -- implements portal policies for types of
content which are "discussable", and how they are linked to
their discussion threads.
'portal_actions' -- list context-specific actions for portal
objects.
'portal_undo' -- provide a portal-friendly interface to Zope's
undo
machinery.
Each of these tools is represented as an interface in the 'PTKBase'
product, with a sample implementation (typically preserving the
"old"
policies/semantics) in the 'PTKDemo' or 'DemoPortal' products. The
single most attractive feature of the design is that portal
managers
can replace these tools on a *per-portal basis*.
* Fabio Forno provided invaluable aid in debugging the new tools.
* One noticeable result of the new architecture is the "renaming of
the toolbox",
http://lists.zope.org/pipermail/zope-ptk/2000-August/001341.html
to the "actions list", in order to avoid confusion with the
"portal
tools."
* Bill Anderson "released a new version",
http://www.zope.org/Members/Bill/News/MembershipRelease-075
of the Membership product, upgrading it to "beta" status. This
product uses ZPatterns to manage member registration and logins,
and is on a trajectory for eventual reintegration with the
new PTK Architecture.
* Chris Withers announced "Swishdot",
http://www.squishdot.org/968089230/index_html, a successor to
the popular Squishdot weblog product, to be built around the
PTK.
* Tres Seaver "proposed",
http://lists.zope.org/pipermail/zope-ptk/2000-August/001430.html
revamping the implementation of the Dublin Core metadata
within the PTK, in order to bring it closer into line with
the intent of the "spec":http://purl.org/DC.
* A "long thread",
http://lists.zope.org/pipermail/zope-ptk/2000-August/001461.html
on "hooking" various portal actions resulted in a "proposal",
http://lists.zope.org/pipermail/zope-ptk/2000-August/001493.html
to create an "event channel" object, 'portal_events', as another
tool.
PTK Tracker Vitals, 2000/09/04 (since 2000/07/25)
Here is is the current state of the tracker::
Type / Status New Closed Current
Bug Reports 5 3 26
Feature/Doc
Requests 0 0 14
---
Zope Web
-- by Ethan Fremen
ZEO Bakes in Zope.org Oven
ZEO is being cooked with Zope.org. This has unfortunately
endengered some downtime, as ZEO bugs step out from hiding.
The bonus is that Zope.org should be much more stable when
this is done, and ZEO users get the benifit of a ZEO that's
been put through it's paces.
The Caching Machine
Zope.org now has its images and files cached by Apache
and any downstream cache that cares to do so. This should
result in a much faster apparent speed for Zope.org,
though we can expect that raw hit-count (as measured by
Apache) may decline. Stay tuned for the How-To.
Go Forth and Multiply
Zope.org is going to be getting a new ZEO client on a
geographically remote machine. Once this is tested and
solid, Zope.org mirroring will expand to several clients
in strategic spots throughout the globe. Watch
this space for more details.
Distributed Decision Making
As a necessary precursor stage for a more active involvement
of the community, messages to webmaster(a)zope.org and issues
posted in the "zope.org Tracker",
http://www.zope.org/Tracker
will be sent to the zope web mailing list.
Hope to see you there!
-EOT-
Announcing HappyDoc, a Python documentation extraction tool.
HappyDoc is a tool for extracting documentation from Python source
code. It differs from other such applications by the fact that it
uses the parse tree for a module to derive the information used in
its output, rather that importing the module directly. This allows
the user to generate documentation for modules which need special
context to be imported.
Version 0.6
Version 0.6 is the first public release. It is described completely
on the home page (see just below). It isn't ready for a 1.0 release
number yet because I want to add a few more core features before
getting to that point. It is stable, however, and is somewhere
between a beta and full-release level.
Download
Download the latest version of HappyDoc from the home page on
SourceForge:
http://sourceforge.net/projects/happydoc
Doc-string Format
How does an author write documentation so that it will be marked up
and look fancy? This is a perennial question for Python, and seems
to have introduced a roadblock into the development of more robust
and useful documentation tools. By separating the formatter classes
from the docset classes, HappyDoc allows a user to create their own
formatter to interpret comments in any way they see fit.
The default for the HTMLTableFormatter (the default formatter for
HappyDoc) is to treat __doc__ strings as StructuredText. Don't like
StructuredText? Write your own formatter that does something
different and drop it into place.
Documentation not in Doc-strings
It is not always desirable to put all documentation in __doc__
strings. Sometime, notably when working with Zope, special meaning
is attached to the presence of __doc__ strings. For this reason,
and to support existing code which might not have __doc__ strings,
HappyDoc will find and extract documentation in Python comments.
Comment documentation can contain all of the same formatting as
__doc__ strings. The preceding comment marker will be stripped off
and the lines will be assembled and treated as a block of
StructuredText.
To use this feature, it is important to place the comments
**before** the named object which they describe. In this example:
#
# Class documentation goes here
#
class ClassWithNoDocStrings:
"Using __doc__ strings overrides comment documentation."
def method1(self, params):
"This method uses a __doc__ string."
pass
#
# Method2 does not use a __doc__ string.
#
def method2(self):
pass
The output would include the __doc__ strings for the class and for
method1. It would also make it appear that method2 had a __doc__
string with the contents "Method2 does not use a __doc__ string."
Feedback on HappyDoc is welcome to doughellmann(a)bigfoot.com.
Doug Hellmann
I've packaged the ZODB using the Distutils. There are 3 packages,
containing the ZODB itself, ExtensionClass, and a few miscellaneous
Python modules that are required.
Installation instructions are at
http://starship.python.net/crew/amk/zodb/install.html
The packages themselves are available through FTP from:
ftp://starship.python.net/pub/crew/amk/zodb/
This repackaging is aimed at people who want to use the ZODB in their
own programs without using other Zope features; it will save the
effort of figuring out which bits of Zope need to get installed. The
packaging is still experimental, so please inform me if you run into
problems during the installation process.
Future plans are to merge the 3 packages into a single package, and
also package ZEO.
--amk
