Saravanan666/pypi-org huggingface dataset:
Package: dmtoqt
This documentation resides athttps://controls.als.lbl.gov/alscg/dmtoqt/latest.Overviewdmtoqt takes EDM files (.edl) as input, and writes Qt Designer UI files (.ui).  It takes advantage
of EPICS-aware Qt widget frameworks to mimic the intent and appearance of the original EDM user interfaces
as closely as possible.SynpopsisInvoke dmtoqt like:python dmtoqt.py --help
usage: dmtoqt.py [-h] [-v | -q] [-p PATH] [-c COLORS]
                                   [-f FRAMEWORK [FRAMEWORK ...]]
                                   file [file ...]
Convert EDM files to epicsqt-aware Qt ui files (for more details, please visit
https://controls.als.lbl.gov/alscg/dmtoqt)
positional arguments:
        file File(s) to convert. Glob-style wildcards may be used.
                 If no extension is provided, .edl will be added.
                 Output goes to {file}.ui
optional arguments:
        -h, --helpshow this help message and exit
        -v, --verbose Turn on verbose output
        -q, --quiet Be vewwy quiet
        -p PATH, --path PATHPath in which to look for input files and write output
                files
        -c COLORS, --colors COLORS
                Path to colors.list file. If not provided, will look
                in $EDMOBJECTS, $EDMPVOBJECTS, /etc/edm/edmobjects
        -f FRAMEWORK [FRAMEWORK ...], --framework FRAMEWORK [FRAMEWORK ...]
                Use framework "EpicsQt" and/or "caQtDM". If only one
                argument is provided, only that framework will be
                used; if both are specified the best match for each
                widget will be chosen. Default is to use EpicsQt onlyRunning dmtoqtNormally, the only arguments required are the filename(s) of EDM files to be converted.
These may be glob-style wildcards, in which case all matching files will be read.Examples:One or more input files:python dmtoqt.py linac.edl booster.edlReads linac.edl and booster.edl from the current working directory, and produces
linac.ui and booster.ui in the same directory.  EpicsQt widgets will be produced.Specifying a path:python dmtoqt.py -p /usr/local/epics opi/*.edlReads all .edl files in /usr/local/epics/opi, and writes .ui files in the same
directory.  The filenames will match the input filenames; that is, if a file
/usr/local/epics/opi/linac.edl exists, /usr/local/epics/opi/linac.ui will be written.Forcing use of caQtDM Widgets:python dmtoqt.py -f caQtDM linac.edlReads linac.edl from the current directory, and writes linac.ui.  Only caQtDM
widgets will be used.  (CAUTION: caQtDM is not fully supported as of this writing)Using multiple frameworks:python dmtoqt.py -f caQtDM EpicsQt linac.edlReads linac.edl from the current directory, and writes linac.ui.  Widgets will
be EpicsQt or caQtDM, depending on which framework is most suitable for the input EDM widget.
(CAUTION: Since caQtDM is not fully supported, this may not always provide optimal results.)
Package: dm.transaction.aborthook
This package defines the parameterless functionadd_abort_hookswhich patchestransactionto support (before and after) abort hooks.The support is analogous to that of before commit hooks.
Especially,transaction._transaction.Transactiongets two new methodsaddBeforeAbortHookandaddAfterAbortHookanaloguous toaddBeforeCommitHookwith identical
signature. The hooks are called at the begin or end,
respectively, ofTransaction.abort().Note that the abort hooks are not called when the transaction
is internally aborted during a transaction commit. In this case,
the after commit hooks are called (withFalseas first parameter).
Therefore, it is likely that you will register a corresponding
pair of abort hook and after commit hook.
In fact, I had expected that the after commit hooks would be called
duringabortas well, but the ZODB developers decided that not calling
them onabortis a feature, not a bug.
Package: dm-tree
Treetreeis a library for working with nested data structures. In a way,treegeneralizes the builtinmapfunction which only supports flat sequences,
and allows to apply a function to each "leaf" preserving the overall
structure.>>>importtree>>>structure=[[1],[[[2,3]]],[4]]>>>tree.flatten(structure)[1,2,3,4]>>>tree.map_structure(lambdav:v**2,structure)[[1],[[[4,9]]],[16]]treeis backed by an optimized C++ implementation suitable for use in
demanding applications, such as machine learning models.InstallationFrom PyPI:$pipinstalldm-treeDirectly from github using pip:$pipinstallgit+git://github.com/deepmind/tree.gitBuild from source:$pythonsetup.pyinstallSupportIf you are having issues, please let us know by filing an issue on ourissue tracker.LicenseThe project is licensed under the Apache 2.0 license.
Package: dmx485
DMX485RequirementsThis script requires pyserial.pip install --user pyserialInstallationInstall from pip:pip install --user dmx485Install from source:python setup.py installHardware CompatibilityThis should work with any FTDI RS485 dongle or any of the similar knock-offs.FTDI to RS485 cheap dongle:https://fr.aliexpress.com/item/USB-to-TTL-RS485-Serial-Converter-Adapter-FTDI-Module-FT232RL-SN75176-double-function-double/32771847720.html?spm=a2g0w.search0104.3.15.63586239S7KSon&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_319_10892_317_10696_453_10084_454_10083_10618_10304_10307_10820_10821_538_537_10302_536_10843_10059_10884_10887_100031_321_322_10103,searchweb201603_51,ppcSwitch_0&algo_expid=6957aa39-4868-4f8d-ac7f-b10f610a4a24-2&algo_pvid=6957aa39-4868-4f8d-ac7f-b10f610a4a24Hardware Examplehttps://stevenbreuls.com/2013/05/diy-usb-dmx-dongle-interface-for-under-10/UsageFirst create an instance of dmx.DMX_Serial(), then start the background thread. Once that is running the dongle will begin sending a full DMX universe.
To change the value of a channel use set_data(). This function takes a bytes() object with 512 bytes, each representing a single DMX channel. It will be sent on the next DMX refresh.import time
import dmx

sender = dmx.DMX_Serial()
sender.start()
for i in range(200):
    if i % 2:
        sender.set_data(bytes((255,)*512))
    else:
        sender.set_data(bytes((0,)*512))
    time.sleep(1)
Package: dmx512-client
DMX-512 python serial clientPer limitation of pySerial this utility helps with properly setting the serial port on POSIX/LINUX and detecting
SYNC/BREAK within the stream of dataUsagefromroh.dmx.client.dmx_clientimportDmxClientfromroh.dmx.client.dmx_client_callbackimportDmxClientCallbackfromtypingimportDict# define callback, you can override even just one method, for example data_receivedclassMyDmxCallback(DmxClientCallback):"""Example implementation of all available callback methods"""defsync_lost(self)->None:print("SYNC LOST")defsync_found(self)->None:print("SYNC FOUND")defdata_received(self,monitored_data:Dict[int,int])->None:print("VALID MONITORED DATA:%s"%monitored_data)deffull_data_received(self,data:bytes)->None:pass# use client with /dev/ttyUSB0 port and monitor dmx address no. 1 for valuesc:DmxClient=DmxClient('/dev/ttyUSB0',[1],MyDmxCallback())c.run()Referenceshttps://github.com/pyserial/pyserial/issues/539- Issue about pySerial limitation when consuming DMX-512Using a Raspberry Pi as a PC-DMX interface (Florian Edelmann) - PDFhttps://man7.org/linux/man-pages/man3/termios.3.html- documentation of PARMRK, IGNBRK and BRKINT settings of virtual terminal
Package: dmypy-ls
It leverages mypy.dmypy_server instead of the slow cli interface.First run takes same time as mypy cli, but next are super fast as
mypy.dmypy_server only reload the changed file.It supports diagnostics only.StatusOn works on Open and Save for nowThe on Change could be implemented if the mypy FineGrainedBuildManager
uses BuildSource of the dmypy_server instead of always reread file from
disk…Install$pipinstall--userdmypy-lsvim-lspconfiglua<<EOFrequire("lspconfig.configs")["dmypyls"]={default_config={cmd={'dmypy-ls'},filetypes={'python'},root_dir=lspconfig.util.root_pattern('pyproject.toml','setup.py','setup.cfg','requirements.txt','Pipfile'),single_file_support=true,},}require("lspconfip").dmypyls.setup({})EOF
Package: dm.zdoc
dm.zdocTiny wrapper aroundpydocto make it usable for Zope.Note: Python versions below 2.6 lack good support for namespace
packages inpydoc. While Zope itself does not use
namespace packages before version 2.12 (which uses Python 2.6),
important Zope applications (such as Plone) do use namespace packages.
In these cases, the documentation produced bypydoc(and
by extensionzdoc) is incomplete.Usagezdoccan either be used via the scriptdmzdoc, via module import
or integrated in a running Zope instance.In the first two cases it might be necessary to set
the Zope environment variablesINSTANCE_HOMEandSOFTWARE_HOMEto tellzdocwhere the Zope sources can be found.Use viadmzdocThe scriptdmzdocis installed when you havesetuptoolsinstalled.Otherwise, you must install it yourself. It has the following content:import dm.zdoc; dm.zdoc.cli()dmzdochas the exact same options and parameters aspydoc,
documented inpydoc.Use via module importThe moduledm.zdocdefines the same objects aspydoc,
documented inpydoc.Integrated in a running Zope instanceFor this use, you must install the module in your Zope installation
and activate itsconfigure.zcmlat Zope startup.
This will give the “Zope Root Folder” the view@@zdocwhich presents the documentation in the same way as thepydochttp server.ATTENTION: Exposing the documentation of a Zope instance in this way
provides sensible insights and could give hackers valuable clues for
attacks. Likely, you will install this only in development
instances with restricted access.Version History2.0 support for the “integrated in a runnging Zope instance” use case1.1 works around a bug in eitherzope.interfaceorinspect.
Package: dm.zodb.repair
This package contains a function to restore lost objects from a ZODB backup.
In the future, it might grow further tools for ZODB repair.recover.restore_from_backupThe modulerecoverdefines the functionrestore_from_backupto restore lost objects from a ZODB backup.restore_from_backuphas parameterslost,backupandtarget.lostis an iterable of oids identifying objects lost intarget.
The oids might e.g. have been found by the standardfsrefsutility.backupandtargetare open ZODB storages.backupis read only
and can have been opened read only;targetis read and written.restore_from_backupreads the objects identified by the oids inlostfrombackupand writes them totarget. If such a restored
object contains references to other objects not available intarget,
they are restored recursively.
The operations are logged via Python’s standard logging subsystem.Example usage:from logging import basicConfig, getLogger, INFO
from ZODB.FileStorage.FileStorage import FileStorage
from dm.zodb.repair.recover import restore_from_backup

basicConfig()
logger = getLogger(); logger.setLevel(INFO)

lost = [....] # list of oids for lost objects, e.g. derived from "fsrefs" output

backup = FileStorage('backup.fs', read_only=True)
target = FileStorage('target.fs')
restore_from_backup(lost, backup, target)
backup.close()
target.close()
Package: dm.zopepatches.cookies
This package patches the web application server Zope to improve its
cookie handling.Currently, it definesregister_cookie_param(name,type='string',pname=None)to define additional parameters recognized when cookies are generated.nameis the parameter given to Zope’ssetCookiemethod,pnameis the corresponding parameter name in the generatedSet-Cookieresponse header.
If not specified,pnameis derived fromnameby replacing_by-.typespecifies this parameter’s type. Currently defined values are'string'(normal string, quoted when it contains whitespace, comma or
semicolon),'quoted-string'(a string unconditionally quoted),'boolean'(boolean parameter, only the name and no value is generated),sequence(generates a quoted comma separated sequence).ATTENTIONRFC 6265has drastically simplified theSet-Cookiesyntax
(over the now obsoleteRFC 2965):
it is no longer possible to quote;by
including it in a doubly quoted string. This means that;can no
longer be part of a cookie attribute value
(unlessRFC 2047encoded).Import ofdm.zopepatches.cookies.httponlyprovides forhttponlysupport. It registers bothhttponlyas well ashttp_only.
The former is the spelling consistent with other cookie parameters, the
latter is the spelling used by Zope 2.12.History2.0Made compatible with Python 3 and Zope [4].Made compatible with RFC 6025
Package: dm.zopepatches.fix_responsewrite_conflict
This package patches the web application server Zope to work aroundhttps://bugs.launchpad.net/zope2/+bug/740831.The bug causes Zope to deliver wrong responses after a request usingResponse.writehas suffered aConflictError. The patch
prevents Zope from retrying such requests and logs an error message when it
tries. The bug effect is thus limited to a single request.Note that even with this patch Zope does not behave fully correctly: in
case of aConflictError, it may
deliver a (maybe partial) response even though the transaction has
been aborted. The client does not get feedback for the transaction rollback.
The only indication is the log record written.Response.writeis inherently unsafe in the face ofConflictError.
The only reliable fix is not to use it at all.The (monkey) patch gets installed when this package is imported.
Package: dm.zopepatches.formlib
This package allows to work around
problems/weaknesses inzope.formliband the associated widgets inzope.app.form.browser,
described by “https://bugs.launchpad.net/zope3/+bug/528920”
and “https://bugs.launchpad.net/zope3/+bug/528912”.The package has been developed for Zope 2.10, will probably work for Zope 2.11
and is unlikely to work for very new Zope versions, because the widget
code has been moved fromzope.app.formtozope.formlib.
I may publish versions of this package for new Zope versions in the future.The package consists of various modules described below.To use the package in your application, you import some of its
patch functions (mentioned below) and call them during the startup
of your application.I hope that corresponding patches will sooner or later appear in the
standard Zope code and make this package obsolete.formTogether withwidget, this module is destined to work
aroundhttp://dev.plone.org/plone/ticket/10264andhttps://bugs.launchpad.net/zope3/+bug/528920.zope.formlibdistinguishes between widget related errors
and other (more global) errors. If a widget itself detects a
widget related error (usually because a restriction for the
associated field fails), it sets its error condition.
This error condition is usually used to highlight the widget containing an
error and to provide information about this error.
However, if the widget related error is not detected by the
widget itself, the error is not associated with the widget and
important information may be missing.The functionpatch_action()in moduleformenhanceszope.formlib.form.Actionby an additional methodassociate_errors_with_widgetsand redefines itsfailuremethod to call it unless an explicit failure handler is specified.
This provides for automatic error association with the widgets
in the standard case.associate_errors_with_widgetstries to associatezope.app.form.interfaces.WidgetInputErrorwith
the corresponding widget. For this purpose, the widget
must have asetWidgetInputErrormethod.
By default widgets lack this method. Howeverwidget.patch_widget()can be used to define it. Therefore,form.patch_action()andwidget.patch_widget()are usually used together.widgetTogether withform, this module is destined to work
aroundhttp://dev.plone.org/plone/ticket/10264andhttps://bugs.launchpad.net/zope3/+bug/528920.Itspatch_widget()enhanceszope.app.form.browser.widget.BrowserWidget(the base class forzope.app.formwidgets) by defining the methodsetWidgetInputError.
The method allows external code to set an error condition on the widget.setWidgetInputErroris used by the error handling implemented
by theformmodule. Therefore,widget.patch_widget()is usually
used together withform.patch_action().multiselectionThis module is destined to work aroundhttp://dev.plone.org/plone/ticket/10267andhttps://bugs.launchpad.net/zope3/+bug/528912.Itspatch_OrderedMultiSelectWidget()fixeszope.app.form.browser.itemswidgets.OrderedMultiSelectWidget.Version history2.0Python 3 compatibility
Package: dm.zopepatches.logging
The package provides the functionuse_zope_exception_log_format.
When called, it overrideslogging.Formatter.formatExceptionwith
the effect that later log entries use Zope’s format for exceptions rather
than Python’s. The former contains additional hints from__traceback_info__and__traceback_supplement__found in the
traceback frames.__traceback_info__and/or__traceback_supplement__are often used by the Zope infrastructure or application code
to provide additional information for the analysis of exception
causes. For example, Zope’s page templates use this mechanism
to make available at what position in the template an exception occurred.
Package: dm.zopepatches.security
This package allows to work around
weaknesses in the web application server Zope’s security subsystem.
Currently, it contains a single moduleproxy.proxyIn principle, Zope makes a clear distinction between trusted code
(which comes from the file system and cannot be modified through-the-web)
and untrusted code (which might be tangled with through-the-web).
Trusted code is unrestricted by Zope’s security subsystem,
untrusted code has permission checks on each object and method access.Unfortunately, occasionnally, trusted code performs its own
security checks – and can raiseUnauthorizedexceptions even
when called from other trusted code. Theproxymodule
is destined to work around this behaviour.
It uses Zope’s so calledproxy rolesto set up roles which
should be used for internal security checks.The module defines the context managerproxy_roles(*roles),
typically used as follows:>>> with proxy_roles(role1, role2, ...):
>>>   ... perform any operation[s] with internal security checks ...This sets up proxy rolesrole1, role2, …to be used
for the internal security checks.Usually, the roles are'Manager', 'Authenticated'but can be anything.
Note that proxy roles override any currently active user roles.History2.0Make Python 3/Zope 4 compatible; drop support for Python 2.6 (and below)New “context manager” interface.
Package: dm.zopepatches.xmlrpc
This package patches the web application server Zope to allow
customizable control over the interpretation of requests as xmlrpc requests.
It implements functionality proposed inhttps://bugs.launchpad.net/zope2/+bug/373663.The package has been tested with Zope 2.10.x. It contains special
handling for Zope 2.11 and Zope 2.12. Because each of these
versions requires version specific handling (an indication that
the corresponding Zope code is unstable (in the sense that it changes often)),
it is likely to fail with other Zope versions.Control xmlrpc processingZope has built in xmlrpc support. Unfortunately, this support triggers
as soon as a “POST” request has a “text/xml” content type.
However, there are many “POST” requests which use a “text/xml” content type
but cannot be interpreted as xmlrpc requests, most prominently SOAP 1.1
requests.Starting with Zope 2.12, Zope no longer treats requests with a “SoapAction”
header as xmlrpc requests. This solves the problem for SOAP 1.1
requests; however, in a very ad-hoc way.
This package provides an easily customizable way to control
the recognition of xmlrpc requests.Inpublisher.interfacesit defines the interfaceIXmlrpcChecker.
This interface is destined as an interface implemented by a utility.
Whendm.zopepatches.publisher.interfacesis imported,
Zope’sHTTPRequestis patched such that when the preconditions
for an xmlrpc request as stipulated by the xmlrpc specification
(“POST” request and content typetext/xml) are met, anIXmlrpcCheckerutility is looked up and the request is
interpreted as an xmlrpc request when either no such utility is found
or the utility applied to the request returns true. Otherwise,
the request is treated normally and other parts of the framework or
the application can handle it as appropriate.This means that you simply can register andm.zopepatches.xmlrpc.publisher.interfaces.IXmlrpcCheckerutility when you need control over the triggering of Zope’s
xmlrpc support.
Package: dm.zopepatches.ztest
This package defines the (console) scriptztest, a small wrapper
around the Zope (3) testrunner to run tests of Zope (2) application components
(often so called Zope (2) products).Until Zope 2.11, its functionality was available asbin/zopectl test.
For Zope 2.12,
Zope developers switched tobuildoutfor Zope development itself
and (to save some work) dropped support forbin/zopectl test.
Thus, developers of Zope application components (like me) were forced
either to switch tobuildout, to renounce testing or to build something
likeztest.My experience withbuildouthas not been good: compared with
a more traditional (and more manual)virtualenv,buildoutgave me much more surprises (surprising upgrades),
much more waiting time due to unnecessary rebuildings and was
far less reliable (due to problems of internet servers scanned for
sources). Therefore, I do not want to switch tobuildout.
Of course, I do not want to renounce testing.
Thus, I stiched the Zope 2.11 code together to buildztest.ztestcan also be used together withbuildout.
Abuildoutpart definition forztestcould look like:[ztest]
recipe = zc.recipe.egg:scripts
eggs =
  dm.zopepatches.ztest
  ${buildout:eggs}
extra-paths =
  ${zope2:location}/lib/pythonIt creates a scriptbin/ztestthat can test packages either in
Zope or in the available eggs.Basic usageztest -hlist the available optionsztest [–config-fileconfig_file] -spackagerun tests forpackage. If given, useconfig_fileas the Zope
configuration fileztest [–config-fileconfig_file] –package-pathfile_path_to_packagepackage-spackageoccationally, the testrunner is too stupid to find the tests in a package.
Then it is necessary to specify its file path with the--package-pathoption.History2.0Python 3/Zope4+ compatibilityRequiring modernzope.testrunner(>= 4.9). This makes
this release Python 3 (>= 3.3) and Python 2.7 only.New command line option--loggingto activate basic logging.1.1.3Bugfix: a module filter was usually not effective1.1.2support for Zope 2.101.1try to determine ‘package-path’ automatically by a trial import. May not always work.