The python-couchdb package (used as import couchdb) provides a db.view() function to access a couchdb "_view", but how do you access a "_show" or "_list" function?
This was asked before (http://stackoverflow.com/questions/5491851/couchdb-and-python-how-to-use-show-and-list-functions) and 1 of the authors said that it was now included in the library, but he doesn't mention HOW to use it (db.show() doesn't work) and I can't find any documentation for it online.
Can anyone let me know the function/method - or - point me at a page that explains how to do it. I'm particularly interested in "_show".
Currently, you need to get couchdb-python from repository: there are implemented Database methods to call _show, _list and _update functions.
Related
Good day,
I'm very new to the Blender API.
Ultimately, I am trying to get the currently selected object. I know this is available bpy.context.selected_objects. However, I'm running my script from a python file and the context object is different. in my current context the selected_objects does not exist.
I've searched around and at most I've been able to find that you can edit in which context some operators are run by overriding their settings. But bpy.context.selected_objects is not an operator.
Perhaps there is a method or operator inside bpy.data which returns the selected object? I can't seem to find the part of the documentation which shows what attributes are exposed inside bpy.data https://docs.blender.org/api/current/search.html?q=bpy.data.&check_keywords=yes&area=default#
Thanks in advance.
As your running this from blender scripting possibly using bpy.context.active_object rather then bpy.context.selected_objects might work better.
There can be an active object when no objects are selected, here's more info on them: https://blender.stackexchange.com/questions/27396/whats-the-difference-among-object-active-object-and-selected-objects
It's also quite hard to tell what could be going on without more details on the internal functionings, so attaching code would be usefull.
I would like, given a python module, to monkey patch all functions, classes and attributes it defines. Simply put, I would like to log every interaction a script I do not directly control has with a module I do not directly control. I'm looking for an elegant solution that will not require prior knowledge of either the module or the code using it.
I found several high-level tools that help wrapping, decorating, patching etc... and i've went over the code of some of them, but I cannot find an elegant solution to create a proxy of any given module and automatically proxy it, as seamlessly as possible, except for appending logic to every interaction (record input arguments and return value, for example).
in case someone else is looking for a more complete proxy implementation
Although there are several python proxy solutions similar to those OP is looking for, I could not find a solution that will also proxy classes and arbitrary class objects, as well as automatically proxy functions return values and arguments. Which is what I needed.
I've got some code written for that purpose as part of a full proxying/logging python execution and I may make it into a separate library in the future. If anyone's interested you can find the core of the code in a pull request. Drop me a line if you'd like this as a standalone library.
My code will automatically return wrapper/proxy objects for any proxied object's attributes, functions and classes. The purpose is to log and replay some of the code, so i've got the equivalent "replay" code and some logic to store all proxied objects to a json file.
I have I small module that I use inside one of my projects. Now I decided to place it on github so now I am writing some docstrings and cleaning the code.
I have a composition of 2 classes so the initialization looks like this:
foo = Class_1()
bar = Class_2(param1=foo)
I know that the first argument to the Class_2 has to be an instance of Class_1 or the code won't work. But it may be clear only for me as I wrote code of Class_2, but when using module as API it may be unclear for a user that param1 has to be an instance of Class_1. If someone will use bar = Class_2(param1='foo'). The trackback will be bad and it will be impossible to understand what happened. So the question is: do I need to check in my __init__ that isinstance(param1, Class_1) and if no raise an excaption with an appropriate message, or writing good documentation is enough?
This is very opinion-based (not great for StackOverflow in particular) - but in my opinion, you should do both.
On the one hand, using isinstance() and exception-handling are both good defensive-coding practices.
On the other hand, inline documentation is nice. Per the Python developer guide:
The markup used for the Python documentation is reStructuredText, developed by the docutils project, amended by custom directives and using a toolset named Sphinx to post-process the HTML output.
Some IDEs, such as JetBrains PyCharm, are configured to automatically pick up well-formed reST docstrings and perform automated type-checking based on those conventions (which I've found to be really useful). See also: PEP 257 and What is the standard Python docstring format? for details.
I am new pyomo user. I want to learn that is there any document or way to see all attributes, methods and functions of pyomo? Same issue for CBC.
Source-level documentation is not currently supported for Pyomo. The Pyomo developers have discussed whether/how to make this a priority, but this is not yet the focus of the team.
From the interactive Python shell, you can import a module and then do a help() on it to see documentation included in the module itself:
>>> import pyomo
>>> help(pyomo)
You can also use the dir() command to see a list of all attributes and functions that are in the module:
>>> dir(pyomo)
But I have to ask -- what is wrong with the online documentation at www.pyomo.org? It seems like a very nice homepage for the project.
I'm very new to couch, but I'm trying to use it on a new Python project, and I'd like to use python to write the design documents (views), also. I've already configured Couch to use the couchpy view server, and I can confirm this works by entering some simple map/reduce functions into Futon.
Are there any official recommendations on how to load/synchronize design documents when using Python's couchdb module?
I understand that I can post design documents to "install" them into Couch, but my question is really around best practices. I need some kind of strategy for deploying, both in development environments and in production environments. My intuition is to create a directory and store all of my design documents there, then write some kind of sync script that will upload each one into couch (probably just blindly overwriting what's already there). Is this a good idea?
The documentation for "Writing views in Python" is 5 sentences, and really just explains how to install couchpy. On the project's google code site, there is mention of a couchdb.design module that sounds like it might help, but there's no documentation (that I can find). The source code for that module indicates that it does most of what I'm interested in, but it stops short of actually loading files. I think I should do some kind of module discovery, but I've heard that's non-Pythonic. Advice?
Edit:
In particular, the idea of storing my map/reduce functions inside string literals seems completely hacky. I'd like to write real python code, in a real module, in a real package, with real unit tests. Periodically, I'd like to synchronize my "couch views" package with a couchdb instance.
Here's an approach that seems reasonable. First, I subclass couchdb.design.ViewDefinition. (Comments and pydocs removed for brevity.)
import couchdb.design
import inflection
DESIGN_NAME="version"
class CurrentVersion(couchdb.design.ViewDefinition):
def __init__(self):
map_fun = self.__class__.map
if hasattr(self.__class__, "reduce"):
reduce_fun = self.__class__.reduce
else:
reduce_fun = None
super_args = (DESIGN_NAME,
inflection.underscore(self.__class__.__name__),
map_fun,
reduce_fun,
'python')
super(CurrentVersion, self).__init__(*super_args)
#staticmethod
def map(doc):
if 'version_key' in doc and 'created_ts' in doc:
yield (doc['version_key'], [doc['_id'], doc['created_ts']])
#staticmethod
def reduce(keys, values, rereduce):
max_index = 0
for index, value in enumerate(values):
if value[1] > values[max_index][1]:
max_index = index
return values[max_index]
Now, if I want to synchronize:
import couchdb.design
from couchview.version import CurrentVersion
db = get_couch_db() # omitted for brevity
couchdb.design.ViewDefinition.sync_many(db, [CurrentVersion()], remove_missing=True)
The benefits of this approach are:
Organization. All designs/views exist as modules/classes (respectively) located in a single package.
Real code. My text editor will highlight syntax. I can write unit tests against my map/reduce functions.
The ViewDefinition subclass can also be used for querying.
current_version_view = couchview.version.CurrentVersion()
result = current_version_view(self.db, key=version_key)
It's still not ready for production, but I think this is a big step closer compared to storing map/reduce functions inside string literals.
Edit: I eventually wrote a couple blog posts on this topic, since I couldn't find any other sources of advice:
http://markhaase.com/2012/06/23/couchdb-views-in-python/
http://markhaase.com/2012/07/01/unit-tests-for-python-couchdb-views/