| |
|
| Changed, Enhanced, or Newly Deprecated Features |
Changed, Enhanced, or Newly Deprecated Features |
| |
|
| |
- 'running.ISignalManager' is now DEPRECATED; please use 'events.ISignalSource' |
| |
instead. |
| |
|
| |
- Added 'events.ISignalSource', that returns 'events.Broadcaster' objects for |
| |
signals. This allows you to yield to signals in an 'events.Thread', or |
| |
safely set one-time callbacks on them. |
| |
|
| |
- 'running.IMainLoop' has been changed to use an 'events.IReadable' for |
| |
the 'lastActivity' attribute, and the 'setExitCode' and 'childForked' |
| |
methods have been replaced with an 'exitWith()' method. |
| |
|
| |
- The 'peak.running.mainLoop.signalHandler' property has been replaced with |
| |
'peak.running.mainLoop.stopOnSignals', which defaults to including SIGINT, |
| |
SIGTERM, and SIGBREAK. If you need custom signal handling, please use |
| |
the event sources provided by an 'events.ISignalSource'. |
| |
|
| |
- Simplified configuration for using Twisted, roughly as proposed in |
| |
"this message.":http://www.eby-sarna.com/pipermail/peak/2004-January/001125.html |
| |
|
| |
You can now configure a service area as using Twisted by setting its |
| |
'peak.running.isTwisted' property, or by depending upon the |
| |
'running.ITwistedReactor' interface, as long as it happens early enough. |
| |
|
| |
If you need to make choices based on whether a Twisted reactor is being |
| |
used, you should use the 'peak.running.scheduler.ifTwisted()' function. |
| |
If you would like to try to force a service area to use a Twisted reactor, |
| |
you may use 'peak.running.scheduler.makeTwisted()'. |
| |
|
| |
- Added automatic installation of 'csv' module for Python < 2.3. |
| |
|
| |
- Added 'peak.events' package, supporting a simple event-driven programming |
| |
microkernel, including event-driven "ultralight" threads powered by |
| |
generators. |
| |
|
| |
- "Global" services defined by '[Component Factories]' sections now live in |
| |
the closest "service area" to the component that requests them. A "service |
| |
area" is a parent component that implements 'config.IServiceArea', such as |
| |
a configuration root returned by 'config.makeRoot()'. Applications loaded |
| |
by the 'peak runIni' command are now created in their own service area, |
| |
which means that settings in the .ini file being run will apply to services |
| |
the application uses. (Because the application will have its own, |
| |
application-specific service instances, and they will use the configuration |
| |
loaded into the service area.) |
| |
|
| |
If you need to create your own service area, you can do so by mixing in |
| |
'config.ServiceArea' to your component class. However, you should *not* do |
| |
this unless you know exactly what "outside" services you may need to use |
| |
from "inside" the newly created service area, so that you can explicitly |
| |
connect them "into" the service area. (In short, if you don't know *why* |
| |
you're creating a service area, don't do it.) |
| |
|
| |
- 'config.Namespace()' objects now have a 'keys()' method that can be used |
| |
when the namespace is bound to a context component. It returns a list of |
| |
strings that may be used as keys for that namespace. Example usage:: |
| |
|
| |
>>> from peak.api import * |
| |
>>> r=config.makeRoot() |
| |
>>> ns=config.Namespace('peak.naming.schemes',r) |
| |
>>> ns.keys() |
| |
['https', 'smtp', 'logfile', 'psycopg', 'pkgfile', 'unix.dg', 'win32.dde', |
| |
'sybase', 'timer', 'lockfile', 'pgsql', 'fd.socket', 'uuid', 'tcp', 'file', |
| |
'gadfly', 'http', 'logger', 'icb', 'cxoracle', 'udp', 'winflockfile', |
| |
'import', 'logging.logger', 'nulllockfile', 'nis', 'shlockfile', |
| |
'zconfig.schema', 'flockfile', 'shellcmd', 'dcoracle2', 'config', 'ftp', |
| |
'unix', 'ldap', 'sqlite', 'mockdb'] |
| |
>>> ns['ldap'] |
| |
'peak.storage.LDAP:ldapURL' |
| |
|
| |
- Log events don't use a positional 'message' argument any more, and |
| |
loggers aren't responsible for interpolating message arguments any more. |
| |
The new signature is 'Event(parent, msg=msg, args=args, ...)'. Loggers |
| |
also now tell events what logger name they are, via the 'ident' keyword. |
| |
|
| |
- The logging system now uses a property namespace, 'peak.logging.levels', to |
| |
obtain log level names and values. The various 'logs.LEVEL' constants are |
| |
now DEPRECATED. Please use the 'getLevelFor()' method of the nearest |
| |
'logs.ILoggingService' instead. Also note that URL schemes such as |
| |
'logfile:' no longer convert their level names to numbers, since the |
| |
level names are only meaningful in the context of a logging service. |
| |
|
| |
- Support for integration with the Python 2.3/PEP 282 logging module has been |
| |
scaled back. There are too many globalisms and dependencies there. When we |
| |
add plugin-based log configuration, it should be possible to use the logging |
| |
package's handlers and formatters with the PEAK logging services. At that |
| |
point, you'll be able to replace 'logging.getLogger' and |
| |
'logging.getLevelName' with the corresponding methods of a PEAK logging |
| |
service, if you need to force non-PEAK packages to use PEAK's logging. |
| |
|
| |
- Logs are now accessed via a 'logs.ILoggingService' instance. The 'logger:' |
| |
URL scheme automatically accesses the nearest such service. For backward |
| |
compatibility, the old 'peak.logs' namespace is still used to supply the |
| |
actual loggers. This will be gradually replaced with a plugin-based |
| |
mechanism. |
| |
|
| |
- Added 'binding.PluginKeys' and 'binding.PluginsFor'. These are component |
| |
keys that can be used to 'Obtain' plugins registered within a property |
| |
namespace. 'PluginKeys' obtains a list of the plugins' configuration keys, |
| |
while 'PluginsFor' obtains a list of the actual plugins. |
| |
|
| |
- Replaced 'peak.config.registries.EigenRegistry' with |
| |
'peak.config.registries.ImmutableConfig'. The only use we had for |
| |
'EigenRegistry' was to keep track of 'offerAs' settings within classes, and |
| |
it didn't need all the extra complexity of eigenstate management. The new, |
| |
more-specialized class is shorter, simpler, and easier to use. |
| |
|
| |
- Added 'config.iterKeys()' which iterates over all available configuration |
| |
keys in a given namespace (just property names for now). The 'config:' |
| |
namespace is now a 'naming.IReadContext', so you can navigate it with the |
| |
'n2' command, and do things like 'ls -l config:peak.naming.schemes' to list |
| |
all configured naming schemes. |
| |
|
| |
- Added 'config.parentProviding()' and 'config.parentsProviding()', which |
| |
find the first (or all) parent components of a given component that support |
| |
a given protocol. |
| |
|
| |
- Renamings/refactorings/deprecations in 'peak.config': |
| |
|
| |
'config.getProperty' -- use 'config.lookup()' instead |
| |
|
| |
'config.findUtility' -- use 'config.lookup()' instead |
| |
|
| |
'config.findUtilities' -- use 'config.iterValues()' instead |
| |
|
| |
'config.IPropertyMap' -- use 'config.IConfigMap' or 'config.IConfigurable' |
| |
|
| |
'config.PropertyMap' -- use 'config.ConfigMap' instead |
| |
|
| |
'config.setPropertyFor' -- DEPRECATED, see source for replacement code. |
| |
|
| |
'config.setRuleFor' -- DEPRECATED, see source for replacement code. |
| |
|
| |
'config.setDefaultFor' -- DEPRECATED, see source for replacement code. |
| |
|
| |
'config.instancePerComponent' -- DEPRECATED, use factories instead. |
| |
|
| |
'config.IConfigurationRoot' -- interface has changed; 'propertyNotFound' is |
| |
no longer a method, and 'noMoreUtilities' is now 'noMoreValues'. |
| |
|
| |
'exceptions.PropertyNotFound' -- use 'exceptions.NameNotFound' instead. |
| |
|
| |
'exceptions.OutOfScope' -- REMOVED; it was not actually used in PEAK. |
| |
|
| |
In all cases, the old interface, class, or function is DEPRECATED and will |
| |
go away in the alpha 4 release cycle. Please take particular note of the |
| |
fact that 'IConfigMap' offers virtually none of the convenience |
| |
methods provided by 'IPropertyMap', so adjust your code accordingly. Note |
| |
also that even though there are plenty of references to 'IPropertyMap' |
| |
remaining in PEAK itself, these are strictly to provide backward |
| |
compatibility. Once we enter the alpha 4 release cycle, these will go away. |
| |
|
| - Added 'config.MultiKey()' and 'config.UnionOf()' configuration key classes, |
- Added 'config.MultiKey()' and 'config.UnionOf()' configuration key classes, |
| to generalize existing specialty keys such as 'ProviderOf' and 'FactoryFor'. |
to generalize existing specialty keys such as 'ProviderOf' and 'FactoryFor'. |
| (The latter two are now defined in terms of the former two.) Also, made |
(The latter two are now defined in terms of the former two.) Also, made |
| - Added 'IMainLoop.setExitCode()' and 'IMainLoop.childForked()' methods, to |
- Added 'IMainLoop.setExitCode()' and 'IMainLoop.childForked()' methods, to |
| allow reactor-driven components to control the mainloop's exit code. |
allow reactor-driven components to control the mainloop's exit code. |
| |
|
| - Added 'running.ISignalManager' and a default implementation. Use its |
|
| 'addHandler()/removeHandler()' methods to add or remove signal handlers. |
|
| Signal handlers define methods like 'def SIGCHLD(self,signum,frame):' that |
|
| will be called when the associated signal is received. All active handlers |
|
| for a given signal are invoked, so you can easily have multiple components |
|
| listen for 'SIGCHLD', for example. |
|
| |
|
| - Added 'IBasicReactor.crash()', which forces an immediate reactor loop exit, |
- Added 'IBasicReactor.crash()', which forces an immediate reactor loop exit, |
| ignoring pending scheduled calls. |
ignoring pending scheduled calls. |
| |
|
| property ('peak.running.reactor.checkInterval') to determine how long it |
property ('peak.running.reactor.checkInterval') to determine how long it |
| should run 'select()' calls for, when there are no scheduled tasks. |
should run 'select()' calls for, when there are no scheduled tasks. |
| |
|
| - 'peak.running.scheduler.MainLoop' now supports using a "signal |
|
| handler" component (via the 'peak.running.mainLoop.signalHandler' property) |
|
| to process signals while a 'run()' loop is in progress. Signal handlers can |
|
| also be added or removed at any time via the 'running.ISignalManager' |
|
| service. |
|
| |
|
| - 'peak.running.commands.AbstractCommand' now offers a '_run()' method that |
- 'peak.running.commands.AbstractCommand' now offers a '_run()' method that |
| can be overridden in subclasses, instead of 'run()'. If you override the |
can be overridden in subclasses, instead of 'run()'. If you override the |
| new '_run()' method instead, you get the advantage of automatic handling |
new '_run()' method instead, you get the advantage of automatic handling |
Diff of /PEAK/CHANGES.txt
Parent Directory
| 
Revision Log