[pytango] 68/98: Update autodoc references
Sandor Bodo-Merle
sbodomerle-guest at moszumanska.debian.org
Thu Sep 28 19:17:46 UTC 2017
This is an automated email from the git hooks/post-receive script.
sbodomerle-guest pushed a commit to tag v9.2.0
in repository pytango.
commit 5dec1ade9c1e851bebc045d716b15b2339692e6c
Author: Vincent Michel <vincent.michel at maxlab.lu.se>
Date: Fri Jul 8 18:17:59 2016 +0200
Update autodoc references
---
doc/api.rst | 4 +--
doc/client_api/attribute_proxy.rst | 4 +--
doc/client_api/device_proxy.rst | 4 +--
doc/client_api/green.rst | 17 +++++------
doc/client_api/group.rst | 10 +++----
doc/client_api/miscellaneous.rst | 2 +-
doc/client_api/other.rst | 54 +++++++++++++++++-----------------
doc/contents.rst | 2 +-
doc/data_types.rst | 2 +-
doc/database.rst | 18 ++++++------
doc/encoded.rst | 4 +--
doc/exception.rst | 40 ++++++++++++-------------
doc/faq.rst | 2 +-
doc/green.rst | 30 +++++++++----------
doc/howto.rst | 60 +++++++++++++++++++-------------------
doc/quicktour.rst | 4 +--
doc/server_api/attribute.rst | 12 ++++----
doc/server_api/device.rst | 12 ++++----
doc/server_api/device_class.rst | 4 +--
doc/server_api/index.rst | 2 +-
doc/server_api/logging.rst | 14 ++++-----
doc/server_api/server.rst | 26 ++++++++---------
doc/server_api/util.rst | 4 +--
doc/tep.rst | 2 +-
doc/tep/tep-0001.rst | 48 +++++++++++++++---------------
doc/tep/tep-0002.rst | 4 +--
doc/utilities.rst | 44 ++++++++++++++--------------
27 files changed, 214 insertions(+), 215 deletions(-)
diff --git a/doc/api.rst b/doc/api.rst
index 122da04..8fe07ca 100644
--- a/doc/api.rst
+++ b/doc/api.rst
@@ -1,5 +1,5 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. _pytango-api:
@@ -7,7 +7,7 @@
PyTango API
===========
-.. automodule:: PyTango
+.. automodule:: tango
.. toctree::
:maxdepth: 1
diff --git a/doc/client_api/attribute_proxy.rst b/doc/client_api/attribute_proxy.rst
index 158ed18..45b56e6 100644
--- a/doc/client_api/attribute_proxy.rst
+++ b/doc/client_api/attribute_proxy.rst
@@ -1,9 +1,9 @@
AttributeProxy
--------------
-.. currentmodule:: PyTango
+.. currentmodule:: tango
-.. autoclass:: PyTango.AttributeProxy
+.. autoclass:: tango.AttributeProxy
:members:
diff --git a/doc/client_api/device_proxy.rst b/doc/client_api/device_proxy.rst
index 8c617b7..9679998 100644
--- a/doc/client_api/device_proxy.rst
+++ b/doc/client_api/device_proxy.rst
@@ -1,9 +1,9 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
DeviceProxy
-----------
-.. autoclass:: PyTango.DeviceProxy
+.. autoclass:: tango.DeviceProxy
:show-inheritance:
:members:
:inherited-members:
diff --git a/doc/client_api/green.rst b/doc/client_api/green.rst
index 9048861..c5df3d8 100644
--- a/doc/client_api/green.rst
+++ b/doc/client_api/green.rst
@@ -6,16 +6,15 @@ Green API
=========
Summary:
- * :func:`PyTango.get_green_mode`
- * :func:`PyTango.set_green_mode`
- * :func:`PyTango.futures.DeviceProxy`
- * :func:`PyTango.gevent.DeviceProxy`
+ * :func:`tango.get_green_mode`
+ * :func:`tango.set_green_mode`
+ * :func:`tango.futures.DeviceProxy`
+ * :func:`tango.gevent.DeviceProxy`
-.. autofunction:: PyTango.get_green_mode
+.. autofunction:: tango.get_green_mode
-.. autofunction:: PyTango.set_green_mode
+.. autofunction:: tango.set_green_mode
-.. autofunction:: PyTango.futures.DeviceProxy
-
-.. autofunction:: PyTango.gevent.DeviceProxy
+.. autofunction:: tango.futures.DeviceProxy
+.. autofunction:: tango.gevent.DeviceProxy
diff --git a/doc/client_api/group.rst b/doc/client_api/group.rst
index 025c1dc..7d604c7 100644
--- a/doc/client_api/group.rst
+++ b/doc/client_api/group.rst
@@ -2,7 +2,7 @@
Group
-----
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. GroupElement is the base class of Group, but is not the base of
@@ -12,7 +12,7 @@ Group
Group class
~~~~~~~~~~~
-.. autoclass:: PyTango.Group
+.. autoclass:: tango.Group
:show-inheritance:
:inherited-members:
:members:
@@ -29,15 +29,15 @@ but objects that contain them. This is:
- *command inout* family returns PyTango.GroupCmdReplyList
The Group*ReplyList objects are just list-like objects containing
-:class:`~PyTango.GroupReply`, :class:`~PyTango.GroupAttrReply` and
+:class:`~tango.GroupReply`, :class:`~tango.GroupAttrReply` and
:class:`~GroupCmdReply` elements that will be described now.
Note also that GroupReply is the base of GroupCmdReply and GroupAttrReply.
-.. autoclass:: PyTango.GroupReply
+.. autoclass:: tango.GroupReply
:members:
-.. autoclass:: PyTango.GroupAttrReply
+.. autoclass:: tango.GroupAttrReply
:show-inheritance:
:members:
diff --git a/doc/client_api/miscellaneous.rst b/doc/client_api/miscellaneous.rst
index 27905d5..d0666e5 100644
--- a/doc/client_api/miscellaneous.rst
+++ b/doc/client_api/miscellaneous.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
API util
--------
diff --git a/doc/client_api/other.rst b/doc/client_api/other.rst
index f50b8b4..315176e 100644
--- a/doc/client_api/other.rst
+++ b/doc/client_api/other.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
Enumerations & other classes
----------------------------
@@ -6,60 +6,60 @@ Enumerations & other classes
Enumerations
~~~~~~~~~~~~
-.. autoclass:: PyTango.LockerLanguage
+.. autoclass:: tango.LockerLanguage
-.. autoclass:: PyTango.CmdArgType
+.. autoclass:: tango.CmdArgType
-.. autoclass:: PyTango.MessBoxType
+.. autoclass:: tango.MessBoxType
-.. autoclass:: PyTango.PollObjType
+.. autoclass:: tango.PollObjType
-.. autoclass:: PyTango.PollCmdCode
+.. autoclass:: tango.PollCmdCode
-.. autoclass:: PyTango..SerialModel
+.. autoclass:: tango..SerialModel
-.. autoclass:: PyTango.AttReqType
+.. autoclass:: tango.AttReqType
-.. autoclass:: PyTango.LockCmdCode
+.. autoclass:: tango.LockCmdCode
-.. autoclass:: PyTango.LogLevel
+.. autoclass:: tango.LogLevel
-.. autoclass:: PyTango.LogTarget
+.. autoclass:: tango.LogTarget
-.. autoclass:: PyTango.EventType
+.. autoclass:: tango.EventType
-.. autoclass:: PyTango.KeepAliveCmdCode
+.. autoclass:: tango.KeepAliveCmdCode
-.. autoclass:: PyTango.AccessControlType
+.. autoclass:: tango.AccessControlType
-.. autoclass:: PyTango.asyn_req_type
+.. autoclass:: tango.asyn_req_type
-.. autoclass:: PyTango.cb_sub_model
+.. autoclass:: tango.cb_sub_model
-.. autoclass:: PyTango.AttrQuality
+.. autoclass:: tango.AttrQuality
-.. autoclass:: PyTango.AttrWriteType
+.. autoclass:: tango.AttrWriteType
-.. autoclass:: PyTango.AttrDataFormat
+.. autoclass:: tango.AttrDataFormat
-.. autoclass:: PyTango.PipeWriteType
+.. autoclass:: tango.PipeWriteType
-.. autoclass:: PyTango.DevSource
+.. autoclass:: tango.DevSource
-.. autoclass:: PyTango.ErrSeverity
+.. autoclass:: tango.ErrSeverity
-.. autoclass:: PyTango.DevState
+.. autoclass:: tango.DevState
-.. autoclass:: PyTango.DispLevel
+.. autoclass:: tango.DispLevel
-.. autoclass:: PyTango.GreenMode
+.. autoclass:: tango.GreenMode
Other classes
~~~~~~~~~~~~~
-.. autoclass:: PyTango.Release
+.. autoclass:: tango.Release
:members:
-.. autoclass:: PyTango.TimeVal
+.. autoclass:: tango.TimeVal
:members:
diff --git a/doc/contents.rst b/doc/contents.rst
index f17733c..41f0889 100644
--- a/doc/contents.rst
+++ b/doc/contents.rst
@@ -1,5 +1,5 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. _contents:
diff --git a/doc/data_types.rst b/doc/data_types.rst
index 483e621..4b2b2e4 100644
--- a/doc/data_types.rst
+++ b/doc/data_types.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. _pytango-data-types:
diff --git a/doc/database.rst b/doc/database.rst
index 3a3eefd..0d6b3c3 100644
--- a/doc/database.rst
+++ b/doc/database.rst
@@ -1,29 +1,29 @@
Database API
============
-.. currentmodule:: PyTango
+.. currentmodule:: tango
-.. autoclass:: PyTango.Database
+.. autoclass:: tango.Database
:members:
-.. autoclass:: PyTango.DbDatum
+.. autoclass:: tango.DbDatum
:members:
-.. autoclass:: PyTango.DbDevExportInfo
+.. autoclass:: tango.DbDevExportInfo
:members:
-.. autoclass:: PyTango.DbDevExportInfo
+.. autoclass:: tango.DbDevExportInfo
:members:
-.. autoclass:: PyTango.DbDevImportInfo
+.. autoclass:: tango.DbDevImportInfo
:members:
-.. autoclass:: PyTango.DbDevInfo
+.. autoclass:: tango.DbDevInfo
:members:
-.. autoclass:: PyTango.DbHistory
+.. autoclass:: tango.DbHistory
:members:
-.. autoclass:: PyTango.DbServerInfo
+.. autoclass:: tango.DbServerInfo
:members:
diff --git a/doc/encoded.rst b/doc/encoded.rst
index 8851023..8dd51a9 100644
--- a/doc/encoded.rst
+++ b/doc/encoded.rst
@@ -6,7 +6,7 @@ Encoded API
*This feature is only possible since PyTango 7.1.4*
-.. currentmodule:: PyTango
+.. currentmodule:: tango
-.. autoclass:: PyTango.EncodedAttribute
+.. autoclass:: tango.EncodedAttribute
:members:
diff --git a/doc/exception.rst b/doc/exception.rst
index cd18dc8..b079585 100644
--- a/doc/exception.rst
+++ b/doc/exception.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. highlight:: python
:linenothreshold: 4
@@ -57,13 +57,13 @@ all of which containing the following kind of key-value pairs:
Throwing exception in a device server
-------------------------------------
-The C++ :class:`~PyTango::Except` class with its most important methods have
+The C++ :class:`~tango::Except` class with its most important methods have
been wrapped to Python. Therefore, in a Python device server, you have the
following methods to throw, re-throw or print a Tango::DevFailed exception :
-- :meth:`~PyTango.Except.throw_exception` which is a static method
-- :meth:`~PyTango.Except.re_throw_exception` which is also a static method
-- :meth:`~PyTango.Except.print_exception` which is also a static method
+- :meth:`~tango.Except.throw_exception` which is a static method
+- :meth:`~tango.Except.re_throw_exception` which is also a static method
+- :meth:`~tango.Except.print_exception` which is also a static method
The following code is an example of a command method requesting a command on a
sub-device and re-throwing the exception in case of::
@@ -83,19 +83,19 @@ sub-device and re-throwing the exception in case of::
Exception API
-------------
-.. autoclass:: PyTango.Except
+.. autoclass:: tango.Except
:show-inheritance:
:members:
-.. autoclass:: PyTango.DevError
+.. autoclass:: tango.DevError
:show-inheritance:
:members:
-.. autoexception:: PyTango.DevFailed
+.. autoexception:: tango.DevFailed
:show-inheritance:
:members:
-.. autoexception:: PyTango.ConnectionFailed
+.. autoexception:: tango.ConnectionFailed
:show-inheritance:
This exception is thrown when a problem occurs during the connection
@@ -120,7 +120,7 @@ Exception API
The device name
-.. autoexception:: PyTango.CommunicationFailed
+.. autoexception:: tango.CommunicationFailed
:show-inheritance:
This exception is thrown when a communication problem is detected during
@@ -147,7 +147,7 @@ Exception API
+-------+-------------------------+----------------------------------------------------+----------+
-.. autoexception:: PyTango.WrongNameSyntax
+.. autoexception:: tango.WrongNameSyntax
:show-inheritance:
This exception has only one level of Tango::DevError structure. The possible
@@ -171,7 +171,7 @@ value for the reason field are :
**API_WrongWildcardUsage**
This error occurs if there is a bad usage of the wildcard character
-.. autoexception:: PyTango.NonDbDevice
+.. autoexception:: tango.NonDbDevice
:show-inheritance:
This exception has only one level of Tango::DevError structure. The reason
@@ -179,7 +179,7 @@ value for the reason field are :
when using the DeviceProxy or AttributeProxy class database access for
non-database device.
-.. autoexception:: PyTango.WrongData
+.. autoexception:: tango.WrongData
:show-inheritance:
This exception has only one level of Tango::DevError structure.
@@ -204,7 +204,7 @@ value for the reason field are :
This error occurs when trying to extract command data with a type
different than the type used to send the data
-.. autoexception:: PyTango.NonSupportedFeature
+.. autoexception:: tango.NonSupportedFeature
:show-inheritance:
This exception is thrown by the API layer when a request to a feature
@@ -212,7 +212,7 @@ value for the reason field are :
implementing Tango device interface n-x. There is one possible value for
the reason field which is API_UnsupportedFeature.
-.. autoexception:: PyTango.AsynCall
+.. autoexception:: tango.AsynCall
:show-inheritance:
This exception is thrown by the API layer when a the asynchronous model id
@@ -231,7 +231,7 @@ value for the reason field are :
request (For instance, using the asynchronous request identifier returned
by a command_inout_asynch() method with a read_attribute_reply() attribute).
-.. autoexception:: PyTango.AsynReplyNotArrived
+.. autoexception:: tango.AsynReplyNotArrived
:show-inheritance:
This exception is thrown by the API layer when:
@@ -241,7 +241,7 @@ value for the reason field are :
There is one possible value for the reason field which is API_AsynReplyNotArrived.
-.. autoexception:: PyTango.EventSystemFailed
+.. autoexception:: tango.EventSystemFailed
:show-inheritance:
This exception is thrown by the API layer when subscribing or unsubscribing
@@ -269,7 +269,7 @@ value for the reason field are :
method
-.. autoexception:: PyTango.DeviceUnlocked
+.. autoexception:: tango.DeviceUnlocked
:show-inheritance:
This exception is thrown by the API layer when a device locked by the
@@ -284,11 +284,11 @@ value for the reason field are :
side. The second layer is added by the client API layer with informations on
which API call generates the exception and device name.
-.. autoexception:: PyTango.NotAllowed
+.. autoexception:: tango.NotAllowed
:show-inheritance:
-.. autoexception:: PyTango.NamedDevFailedList
+.. autoexception:: tango.NamedDevFailedList
:show-inheritance:
This exception is only thrown by the DeviceProxy::write_attributes()
diff --git a/doc/faq.rst b/doc/faq.rst
index 2ab7532..787b3d9 100644
--- a/doc/faq.rst
+++ b/doc/faq.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. _pytango-faq:
diff --git a/doc/green.rst b/doc/green.rst
index 00cbeff..2f8a218 100644
--- a/doc/green.rst
+++ b/doc/green.rst
@@ -1,15 +1,15 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
Green mode
----------
PyTango supports cooperative green Tango objects. Since version 8.1 two *green*
-modes have been added: :obj:`~PyTango.GreenMode.Futures` and
-:obj:`~PyTango.GreenMode.Gevent`.
+modes have been added: :obj:`~tango.GreenMode.Futures` and
+:obj:`~tango.GreenMode.Gevent`.
-The :obj:`~PyTango.GreenMode.Futures` uses the standard python module
+The :obj:`~tango.GreenMode.Futures` uses the standard python module
:mod:`concurrent.futures`.
-The :obj:`~PyTango.GreenMode.Gevent` mode uses the well known gevent_ library.
+The :obj:`~tango.GreenMode.Gevent` mode uses the well known gevent_ library.
Currently, in version 8.1, only :class:`DeviceProxy` has been modified to work
in a green cooperative way. If the work is found to be useful, the same can
@@ -71,12 +71,12 @@ Using :mod:`concurrent.futures` cooperative mode in PyTango is relatively easy::
>>> print(dev.state())
RUNNING
-The :func:`PyTango.futures.DeviceProxy` API is exactly the same as the standard
-:class:`~PyTango.DeviceProxy`. The difference is in the semantics of the methods
+The :func:`tango.futures.DeviceProxy` API is exactly the same as the standard
+:class:`~tango.DeviceProxy`. The difference is in the semantics of the methods
that involve synchronous network calls (constructor included) which may block
the execution for a relatively big amount of time.
The list of methods that have been modified to accept *futures* semantics are,
-on the :func:`PyTango.futures.DeviceProxy`:
+on the :func:`tango.futures.DeviceProxy`:
* Constructor
* :meth:`~DeviceProxy.state`
@@ -89,7 +89,7 @@ on the :func:`PyTango.futures.DeviceProxy`:
* :meth:`~DeviceProxy.ping`
So how does this work in fact? I see no difference from using the *standard*
-:class:`~PyTango.DeviceProxy`.
+:class:`~tango.DeviceProxy`.
Well, this is, in fact, one of the goals: be able to use a *futures* cooperation
without changing the API. Behind the scenes the methods mentioned before have
been modified to be able to work cooperatively.
@@ -103,7 +103,7 @@ the method to execute. The default is `None` which means wait forever. If *wait*
is set to `False`, the *timeout* is ignored.
If *wait* is set to `True`, the result is the same as executing the
-*standard* method on a :class:`~PyTango.DeviceProxy`.
+*standard* method on a :class:`~tango.DeviceProxy`.
If, *wait* is set to `False`, the result will be a
:class:`concurrent.futures.Future`. In this case, to get the actual value
you will need to do something like::
@@ -175,12 +175,12 @@ Using gevent_ cooperative mode in PyTango is relatively easy::
>>> print(dev.state())
RUNNING
-The :func:`PyTango.gevent.DeviceProxy` API is exactly the same as the standard
-:class:`~PyTango.DeviceProxy`. The difference is in the semantics of the methods
+The :func:`tango.gevent.DeviceProxy` API is exactly the same as the standard
+:class:`~tango.DeviceProxy`. The difference is in the semantics of the methods
that involve synchronous network calls (constructor included) which may block
the execution for a relatively big amount of time.
The list of methods that have been modified to accept *gevent* semantics are,
-on the :func:`PyTango.gevent.DeviceProxy`:
+on the :func:`tango.gevent.DeviceProxy`:
* Constructor
* :meth:`~DeviceProxy.state`
@@ -193,7 +193,7 @@ on the :func:`PyTango.gevent.DeviceProxy`:
* :meth:`~DeviceProxy.ping`
So how does this work in fact? I see no difference from using the *standard*
-:class:`~PyTango.DeviceProxy`.
+:class:`~tango.DeviceProxy`.
Well, this is, in fact, one of the goals: be able to use a gevent cooperation
without changing the API. Behind the scenes the methods mentioned before have
been modified to be able to work cooperatively with other greenlets.
@@ -207,7 +207,7 @@ the method to execute. The default timeout is `None` which means wait forever.
If *wait* is set to `False`, the *timeout* is ignored.
If *wait* is set to `True`, the result is the same as executing the
-*standard* method on a :class:`~PyTango.DeviceProxy`.
+*standard* method on a :class:`~tango.DeviceProxy`.
If, *wait* is set to `False`, the result will be a
:class:`gevent.event.AsyncResult`. In this case, to get the actual value
you will need to do something like::
diff --git a/doc/howto.rst b/doc/howto.rst
index 95b46f5..7b51ca8 100644
--- a/doc/howto.rst
+++ b/doc/howto.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. highlight:: python
:linenothreshold: 3
@@ -296,7 +296,7 @@ This is explained in details in the
Since version 8.1, PyTango provides a helper module which simplifies the
development of a Tango device server. This helper is provided through the
-:mod:`PyTango.server` module.
+:mod:`tango.server` module.
Here is a simple example on how to write a *Clock* device server using the
high level API
@@ -338,31 +338,31 @@ high level API
**line 7**
tango device class definition. A Tango device must inherit from
- :class:`PyTango.server.Device`
+ :class:`tango.server.Device`
**line 8**
mandatory *magic* line. A Tango device must define the metaclass as
- :class:`PyTango.server.DeviceClass`. This has to be done due to a limitation
+ :class:`tango.server.DeviceClass`. This has to be done due to a limitation
on boost-python
**line 10-12**
definition of the *time* attribute. By default, attributes are double, scalar,
- read-only. Check the :class:`~PyTango.server.attribute` for the complete
+ read-only. Check the :class:`~tango.server.attribute` for the complete
list of attribute options.
**line 14-16**
the method *strftime* is exported as a Tango command. In receives a string
as argument and it returns a string. If a method is to be exported as a
Tango command, it must be decorated as such with the
- :func:`~PyTango.server.command` decorator
+ :func:`~tango.server.command` decorator
**line 18-23**
- definition of the *info* pipe. Check the :class:`~PyTango.server.pipe`
+ definition of the *info* pipe. Check the :class:`~tango.server.pipe`
for the complete list of pipe options.
**line 28**
start the Tango run loop. The mandatory argument is a list of python classes
- that are to be exported as Tango classes. Check :func:`~PyTango.server.run`
+ that are to be exported as Tango classes. Check :func:`~tango.server.run`
for the complete list of options
Here is a more complete example on how to write a *PowerSupply* device server
@@ -467,13 +467,13 @@ Basic logging
~~~~~~~~~~~~~
The most basic way to write a log message on your device is to use the
-:class:`~PyTango.server.Device` logging related methods:
+:class:`~tango.server.Device` logging related methods:
- * :meth:`~PyTango.server.Device.debug_stream`
- * :meth:`~PyTango.server.Device.info_stream`
- * :meth:`~PyTango.server.Device.warn_stream`
- * :meth:`~PyTango.server.Device.error_stream`
- * :meth:`~PyTango.server.Device.fatal_stream`
+ * :meth:`~tango.server.Device.debug_stream`
+ * :meth:`~tango.server.Device.info_stream`
+ * :meth:`~tango.server.Device.warn_stream`
+ * :meth:`~tango.server.Device.error_stream`
+ * :meth:`~tango.server.Device.fatal_stream`
Example::
@@ -539,11 +539,11 @@ value. Your output would look something like::
1282208997 [-1215965504] DEBUG test/pydsexp/1 <- read_Long_attr()
Decorators exist for all tango log levels:
- * :class:`PyTango.DebugIt`
- * :class:`PyTango.InfoIt`
- * :class:`PyTango.WarnIt`
- * :class:`PyTango.ErrorIt`
- * :class:`PyTango.FatalIt`
+ * :class:`tango.DebugIt`
+ * :class:`tango.InfoIt`
+ * :class:`tango.WarnIt`
+ * :class:`tango.ErrorIt`
+ * :class:`tango.FatalIt`
The decorators receive three optional arguments:
* show_args - shows method arguments in log message (defaults to False)
@@ -712,16 +712,16 @@ There are two ways to create a new device which are described below.
Tango imposes a limitation: the tango class(es) of the device(s) that is(are)
to be created must have been registered before the server starts.
If you use the high level API, the tango class(es) must be listed in the call
-to :func:`~PyTango.server.run`. If you use the lower level server API, it must
-be done using individual calls to :meth:`~PyTango.Util.add_class`.
+to :func:`~tango.server.run`. If you use the lower level server API, it must
+be done using individual calls to :meth:`~tango.Util.add_class`.
Dynamic device from a known tango class name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If you know the tango class name but you don't have access to the :class:`PyTango.DeviceClass`
+If you know the tango class name but you don't have access to the :class:`tango.DeviceClass`
(or you are too lazy to search how to get it ;-) the way to do it is call
-:meth:`~PyTango.Util.create_device` / :meth:`~PyTango.Util.delete_device`.
+:meth:`~tango.Util.create_device` / :meth:`~tango.Util.delete_device`.
Here is an example of implementing a tango command on one of your devices that
creates a device of some arbitrary class (the example assumes the tango commands
'CreateDevice' and 'DeleteDevice' receive a parameter of type DevVarStringArray
@@ -753,9 +753,9 @@ some device properties.
Dynamic device from a known tango class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If you already have access to the :class:`~PyTango.DeviceClass` object that
+If you already have access to the :class:`~tango.DeviceClass` object that
corresponds to the tango class of the device to be created you can call directly
-the :meth:`~PyTango.DeviceClass.create_device` / :meth:`~PyTango.DeviceClass.delete_device`.
+the :meth:`~tango.DeviceClass.create_device` / :meth:`~tango.DeviceClass.delete_device`.
For example, if you wish to create a clone of your device, you can create a
tango command called *Clone*::
@@ -896,10 +896,10 @@ form of a command definition is:
``'cmd_name' : [ [in_type, <"In desc">], [out_type, <"Out desc">], <{opt parameters}>]``
The first element of the value list is itself a list with the command input
-data type (one of the :class:`PyTango.ArgType` pseudo enumeration value) and
+data type (one of the :class:`tango.ArgType` pseudo enumeration value) and
optionally a string describing this input argument. The second element of the
value list is also a list with the command output data type (one of the
-:class:`PyTango.ArgType` pseudo enumeration value) and optionaly a string
+:class:`tango.ArgType` pseudo enumeration value) and optionaly a string
describing it. These two elements are mandatory. The third list element is
optional and allows additional command definition. The authorized element for
this :class:`dict` are summarized in the following array:
@@ -931,10 +931,10 @@ For any kind of attributes, the mandatory parameters are:
``[attr data type, attr data format, attr data R/W type]``
The attribute data type is one of the possible value for attributes of the
-:class:`PyTango.ArgType` pseudo enunmeration. The attribute data format is one
-of the possible value of the :class:`PyTango.AttrDataFormat` pseudo enumeration
+:class:`tango.ArgType` pseudo enunmeration. The attribute data format is one
+of the possible value of the :class:`tango.AttrDataFormat` pseudo enumeration
and the attribute R/W type is one of the possible value of the
-:class:`PyTango.AttrWriteType` pseudo enumeration. For spectrum attribute,
+:class:`tango.AttrWriteType` pseudo enumeration. For spectrum attribute,
you have to add the maximum X size (a number). For image attribute, you have
to add the maximun X and Y dimension (two numbers). The authorized elements for
the :class:`dict` defining optional parameters are summarized in the following
diff --git a/doc/quicktour.rst b/doc/quicktour.rst
index d0627b9..320edc8 100644
--- a/doc/quicktour.rst
+++ b/doc/quicktour.rst
@@ -82,7 +82,7 @@ Client
------
Finally you can get your hands dirty. The first thing to do is start a python
-console and import the :mod:`PyTango` module. The following example shows
+console and import the :mod:`tango` module. The following example shows
how to create a proxy to an existing TANGO device, how to read and write
attributes and execute commands from a python console::
@@ -156,7 +156,7 @@ attributes and execute commands from a python console::
>>>
-This is just the tip of the iceberg. Check the :class:`~PyTango.DeviceProxy` for
+This is just the tip of the iceberg. Check the :class:`~tango.DeviceProxy` for
the complete API.
PyTango comes with an integrated IPython_ based console called :ref:`itango`.
diff --git a/doc/server_api/attribute.rst b/doc/server_api/attribute.rst
index 756dffb..103ff07 100644
--- a/doc/server_api/attribute.rst
+++ b/doc/server_api/attribute.rst
@@ -1,34 +1,34 @@
Attribute classes
=================
-.. currentmodule:: PyTango
+.. currentmodule:: tango
Attr
----
-.. autoclass:: PyTango.Attr
+.. autoclass:: tango.Attr
:members:
Attribute
---------
-.. autoclass:: PyTango.Attribute
+.. autoclass:: tango.Attribute
:members:
WAttribute
----------
-.. autoclass:: PyTango.WAttribute
+.. autoclass:: tango.WAttribute
:members:
MultiAttribute
--------------
-.. autoclass:: PyTango.MultiAttribute
+.. autoclass:: tango.MultiAttribute
:members:
UserDefaultAttrProp
-------------------
-.. autoclass:: PyTango.UserDefaultAttrProp
+.. autoclass:: tango.UserDefaultAttrProp
:members:
diff --git a/doc/server_api/device.rst b/doc/server_api/device.rst
index ce1c421..0da5e4f 100644
--- a/doc/server_api/device.rst
+++ b/doc/server_api/device.rst
@@ -1,18 +1,18 @@
Device
======
-.. currentmodule:: PyTango
+.. currentmodule:: tango
DeviceImpl
----------
-.. autoclass:: PyTango.DeviceImpl
+.. autoclass:: tango.DeviceImpl
:members:
Device_2Impl
------------
-.. autoclass:: PyTango.Device_2Impl
+.. autoclass:: tango.Device_2Impl
:show-inheritance:
:inherited-members:
:members:
@@ -20,7 +20,7 @@ Device_2Impl
Device_3Impl
------------
-.. autoclass:: PyTango.Device_3Impl
+.. autoclass:: tango.Device_3Impl
:show-inheritance:
:inherited-members:
:members:
@@ -28,7 +28,7 @@ Device_3Impl
Device_4Impl
------------
-.. autoclass:: PyTango.Device_4Impl
+.. autoclass:: tango.Device_4Impl
:show-inheritance:
:inherited-members:
:members:
@@ -36,6 +36,6 @@ Device_4Impl
DServer
----------
-.. autoclass:: PyTango.DServer
+.. autoclass:: tango.DServer
:show-inheritance:
:members:
diff --git a/doc/server_api/device_class.rst b/doc/server_api/device_class.rst
index 71c4723..1e9ce30 100644
--- a/doc/server_api/device_class.rst
+++ b/doc/server_api/device_class.rst
@@ -1,7 +1,7 @@
DeviceClass
===========
-.. currentmodule:: PyTango
+.. currentmodule:: tango
-.. autoclass:: PyTango.DeviceClass
+.. autoclass:: tango.DeviceClass
:members:
diff --git a/doc/server_api/index.rst b/doc/server_api/index.rst
index f2a28ef..c3f4d08 100644
--- a/doc/server_api/index.rst
+++ b/doc/server_api/index.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
Server API
----------
diff --git a/doc/server_api/logging.rst b/doc/server_api/logging.rst
index 704b953..1687869 100644
--- a/doc/server_api/logging.rst
+++ b/doc/server_api/logging.rst
@@ -1,40 +1,40 @@
Logging decorators
==================
-.. currentmodule:: PyTango
+.. currentmodule:: tango
LogIt
-----
-.. autoclass:: PyTango.LogIt
+.. autoclass:: tango.LogIt
:members:
DebugIt
-------
-.. autoclass:: PyTango.DebugIt
+.. autoclass:: tango.DebugIt
:members:
InfoIt
------
-.. autoclass:: PyTango.InfoIt
+.. autoclass:: tango.InfoIt
:members:
WarnIt
-------
-.. autoclass:: PyTango.WarnIt
+.. autoclass:: tango.WarnIt
:members:
ErrorIt
-------
-.. autoclass:: PyTango.ErrorIt
+.. autoclass:: tango.ErrorIt
:members:
FatalIt
-------
-.. autoclass:: PyTango.FatalIt
+.. autoclass:: tango.FatalIt
:members:
diff --git a/doc/server_api/server.rst b/doc/server_api/server.rst
index 40a0f6b..8c406e2 100644
--- a/doc/server_api/server.rst
+++ b/doc/server_api/server.rst
@@ -1,23 +1,23 @@
-.. currentmodule:: PyTango.server
+.. currentmodule:: tango.server
.. _pytango-hlapi:
High level server API
=====================
-.. automodule:: PyTango.server
+.. automodule:: tango.server
.. hlist::
- * :class:`~PyTango.server.Device`
- * :class:`~PyTango.server.attribute`
- * :class:`~PyTango.server.command`
- * :class:`~PyTango.server.pipe`
- * :class:`~PyTango.server.device_property`
- * :class:`~PyTango.server.class_property`
- * :func:`~PyTango.server.run`
- * :func:`~PyTango.server.server_run`
+ * :class:`~tango.server.Device`
+ * :class:`~tango.server.attribute`
+ * :class:`~tango.server.command`
+ * :class:`~tango.server.pipe`
+ * :class:`~tango.server.device_property`
+ * :class:`~tango.server.class_property`
+ * :func:`~tango.server.run`
+ * :func:`~tango.server.server_run`
This module provides a high level device server API. It implements
:ref:`TEP1 <pytango-TEP1>`. It exposes an easier API for developing a Tango
@@ -129,16 +129,16 @@ using the high level API. The example contains:
When declaring attributes, properties or commands, one of the most important
information is the data type. It is given by the keyword argument *dtype*.
In order to provide a more *pythonic* interface, this argument is not restricted
-to the :obj:`~PyTango.CmdArgType` options.
+to the :obj:`~tango.CmdArgType` options.
-For example, to define a *SCALAR* :obj:`~PyTango.CmdArgType.DevLong`
+For example, to define a *SCALAR* :obj:`~tango.CmdArgType.DevLong`
attribute you have several possibilities:
#. :obj:`int`
#. 'int'
#. 'int32'
#. 'integer'
-#. :obj:`PyTango.CmdArgType.DevLong`
+#. :obj:`tango.CmdArgType.DevLong`
#. 'DevLong'
#. :obj:`numpy.int32`
diff --git a/doc/server_api/util.rst b/doc/server_api/util.rst
index 7641f66..45558e7 100644
--- a/doc/server_api/util.rst
+++ b/doc/server_api/util.rst
@@ -1,8 +1,8 @@
Util
====
-.. currentmodule:: PyTango
+.. currentmodule:: tango
-.. autoclass:: PyTango.Util
+.. autoclass:: tango.Util
:members:
:inherited-members:
diff --git a/doc/tep.rst b/doc/tep.rst
index d888037..668984c 100644
--- a/doc/tep.rst
+++ b/doc/tep.rst
@@ -1,4 +1,4 @@
-.. currentmodule:: PyTango
+.. currentmodule:: tango
.. _pytango_enhancement_proposals:
diff --git a/doc/tep/tep-0001.rst b/doc/tep/tep-0001.rst
index 3348ff4..f3306a1 100644
--- a/doc/tep/tep-0001.rst
+++ b/doc/tep/tep-0001.rst
@@ -1,5 +1,5 @@
-.. currentmodule:: PyTango.server
+.. currentmodule:: tango.server
.. _pytango-TEP1:
@@ -113,22 +113,22 @@ with the new API.
All tango features should be available by direct usage of the new simplified,
cleaner high-level API and through direct access to the low-level API.
-Automatic inheritance from the latest** :class:`~PyTango.DeviceImpl`
+Automatic inheritance from the latest** :class:`~tango.DeviceImpl`
--------------------------------------------------------------------------------
Currently Devices need to inherit from a direct Tango device implementation
-(:class:`~PyTango.DeviceImpl`, or :class:`~PyTango.Device_2Impl`,
-:class:`~PyTango.Device_3Impl`, :class:`~PyTango.Device_4Impl`, etc)
+(:class:`~tango.DeviceImpl`, or :class:`~tango.Device_2Impl`,
+:class:`~tango.Device_3Impl`, :class:`~tango.Device_4Impl`, etc)
according to the tango version being used during the development.
In order to keep the code up to date with tango, every time a new Tango IDL
is released, the code of **every** device server needs to be manually
updated to ihnerit from the newest tango version.
-By inheriting from a new high-level :class:`~PyTango.server.Device` (which
+By inheriting from a new high-level :class:`~tango.server.Device` (which
itself automatically *decides* from which DeviceImpl version it should
inherit), the device servers are always up to date with the latest tango
-release without need for manual intervention (see :mod:`PyTango.server`).
+release without need for manual intervention (see :mod:`tango.server`).
Low-level way::
@@ -140,14 +140,14 @@ High-level way::
class Motor(PyTango.server.Device):
pass
-Default implementation of :class:`~PyTango.server.Device` constructor
+Default implementation of :class:`~tango.server.Device` constructor
--------------------------------------------------------------------------------
99% of the different device classes which inherit from low level
-:class:`~PyTango.DeviceImpl` only implement `__init__` to call their
-`init_device` (see :mod:`PyTango.server`).
+:class:`~tango.DeviceImpl` only implement `__init__` to call their
+`init_device` (see :mod:`tango.server`).
-:class:`~PyTango.server.Device` already calls init_device.
+:class:`~tango.server.Device` already calls init_device.
Low-level way::
@@ -165,15 +165,15 @@ High-level way::
pass
-Default implementation of :meth:`~PyTango.server.Device.init_device`
+Default implementation of :meth:`~tango.server.Device.init_device`
--------------------------------------------------------------------------------
99% of different device classes which inherit from low level
-:class:`~PyTango.DeviceImpl` have an implementation of `init_device` which
-*at least* calls :meth:`~PyTango.DeviceImpl.get_device_properties`
-(see :mod:`PyTango.server`).
+:class:`~tango.DeviceImpl` have an implementation of `init_device` which
+*at least* calls :meth:`~tango.DeviceImpl.get_device_properties`
+(see :mod:`tango.server`).
-:meth:`~PyTango.server.Device.init_device` already calls :meth:`~PyTango.server.Device.get_device_properties`.
+:meth:`~tango.server.Device.init_device` already calls :meth:`~tango.server.Device.get_device_properties`.
Low-level way::
@@ -188,19 +188,19 @@ High-level way::
# Nothing to be done!
pass
-Remove the need to code :class:`~PyTango.DeviceClass`
+Remove the need to code :class:`~tango.DeviceClass`
--------------------------------------------------------------------------------
99% of different device servers only need to implement their own subclass
-of :class:`~PyTango.DeviceClass` to register the attribute, commands,
+of :class:`~tango.DeviceClass` to register the attribute, commands,
device and class properties by using the corresponding
-:obj:`~PyTango.DeviceClass.attr_list`, :obj:`~PyTango.DeviceClass.cmd_list`,
-:obj:`~PyTango.DeviceClass.device_property_list` and :obj:`~PyTango.DeviceClass.class_property_list`.
+:obj:`~tango.DeviceClass.attr_list`, :obj:`~tango.DeviceClass.cmd_list`,
+:obj:`~tango.DeviceClass.device_property_list` and :obj:`~tango.DeviceClass.class_property_list`.
With the high-level API we completely remove the need to code the
-:class:`~PyTango.DeviceClass` by registering attribute, commands,
-device and class properties in the :class:`~PyTango.server.Device` with a more
-pythonic API (see :mod:`PyTango.server`)
+:class:`~tango.DeviceClass` by registering attribute, commands,
+device and class properties in the :class:`~tango.server.Device` with a more
+pythonic API (see :mod:`tango.server`)
#. Hide `<Device>Class` class completely
@@ -279,7 +279,7 @@ Simplify `main()`
the typical `main()` method could be greatly simplified.
initializing tango, registering tango classes, initializing and running the
server loop and managing errors could all be done with the single function
-call to :func:`~PyTango.server_run`
+call to :func:`~tango.server_run`
Low-level way::
@@ -595,7 +595,7 @@ And the equivalent HLAPI version of the code would be::
References
==========
-:mod:`PyTango.server`
+:mod:`tango.server`
Changes
=======
diff --git a/doc/tep/tep-0002.rst b/doc/tep/tep-0002.rst
index 79307a2..ead4fe3 100644
--- a/doc/tep/tep-0002.rst
+++ b/doc/tep/tep-0002.rst
@@ -1,5 +1,5 @@
-.. currentmodule:: PyTango.databaseds
+.. currentmodule:: tango.databaseds
.. _pytango-TEP2:
@@ -294,7 +294,7 @@ python DataBaseds with sqlite3 implementation.
Development
=================
-The development is being done in PyTango SVN trunk in the :mod:`PyTango.databaseds`
+The development is being done in PyTango SVN trunk in the :mod:`tango.databaseds`
module.
You can checkout with::
diff --git a/doc/utilities.rst b/doc/utilities.rst
index 95975e0..fa1250d 100644
--- a/doc/utilities.rst
+++ b/doc/utilities.rst
@@ -3,48 +3,48 @@
The Utilities API
=================
-.. currentmodule:: PyTango.utils
+.. currentmodule:: tango.utils
-.. autoclass:: PyTango.utils.EventCallBack
+.. autoclass:: tango.utils.EventCallBack
:members:
:undoc-members:
-.. autofunction:: PyTango.utils.is_pure_str
+.. autofunction:: tango.utils.is_pure_str
-.. autofunction:: PyTango.utils.is_seq
+.. autofunction:: tango.utils.is_seq
-.. autofunction:: PyTango.utils.is_non_str_seq
+.. autofunction:: tango.utils.is_non_str_seq
-.. autofunction:: PyTango.utils.is_integer
+.. autofunction:: tango.utils.is_integer
-.. autofunction:: PyTango.utils.is_number
+.. autofunction:: tango.utils.is_number
-.. autofunction:: PyTango.utils.is_bool
+.. autofunction:: tango.utils.is_bool
-.. autofunction:: PyTango.utils.is_scalar_type
+.. autofunction:: tango.utils.is_scalar_type
-.. autofunction:: PyTango.utils.is_array_type
+.. autofunction:: tango.utils.is_array_type
-.. autofunction:: PyTango.utils.is_numerical_type
+.. autofunction:: tango.utils.is_numerical_type
-.. autofunction:: PyTango.utils.is_int_type
+.. autofunction:: tango.utils.is_int_type
-.. autofunction:: PyTango.utils.is_float_type
+.. autofunction:: tango.utils.is_float_type
-.. autofunction:: PyTango.utils.is_bool_type
+.. autofunction:: tango.utils.is_bool_type
-.. autofunction:: PyTango.utils.is_bin_type
+.. autofunction:: tango.utils.is_bin_type
-.. autofunction:: PyTango.utils.is_str_type
+.. autofunction:: tango.utils.is_str_type
-.. autofunction:: PyTango.utils.obj_2_str
+.. autofunction:: tango.utils.obj_2_str
-.. autofunction:: PyTango.utils.seqStr_2_obj
+.. autofunction:: tango.utils.seqStr_2_obj
-.. autofunction:: PyTango.utils.scalar_to_array_type
+.. autofunction:: tango.utils.scalar_to_array_type
-.. autofunction:: PyTango.utils.get_home
+.. autofunction:: tango.utils.get_home
-.. autofunction:: PyTango.utils.requires_pytango
+.. autofunction:: tango.utils.requires_pytango
-.. autofunction:: PyTango.utils.requires_tango
+.. autofunction:: tango.utils.requires_tango
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/pytango.git
More information about the debian-science-commits
mailing list