We Keep Coding

Pdoc - Change template directory programatically

I have a script that generates documentation using pdoc for all of my classes in my project. I want to further customize my documentation by making changes to pdoc templates. I want to do this inside of my project so I can track changes in git, therefor I need to change --template-dir. This is easy enough as a cmd line argument but I have not been able to make this change when using pdoc inside a python script. My question is where can I pass in this argument and or if I make an object of pdoc is there a function or parameter to make this change. Thanks in advance!

The documentation says:
If working with pdoc programmatically, prepend the directory with modified templates into the directories list of the tpl_lookup object.
This is the object in question so something like this should work:
import pdoc
pdoc.tpl_lookup.directories.insert(0, MY_TEMPLATE_DIR)

Django: Python path syntax to my custom validators.py?

I want to implement the solution detailed in this thread but I can't for the life of me figure out the Python path syntax in settings.py needed to link back to my custom validators.py I'm not even sure where to put it. I feel like a simple explanation of how the Python path syntax works in Django ought to be in the docs but after almost 20 minutes of looking through them I don't see anything. Any help would be greatly appreciated.

I'm assuming your custom validators.py is within your project, so like any of your other Python project's module it is accessed using dot notation.
The only thing "different" here is that you append the actual class name to this module string. For example:
AUTH_PASSWORD_VALIDATORS = [
'yourproject.validators.YourValidatorClass',
]
(although the format is not specified in this specific setting in the docs, it is a constant pattern used throughout Django settings)

PyCharm "Run configuration" asking for "script parameters"

While writing an application parsing command line arguments I would like to run it with various parameters.
I don't want to create a Run Configuration for every possible command line argument that I want my script to test with. Is there a way in PyCharm (and I guess with any JetBrains IDE) to make a Run Configuration that asks for the Script parameters when executed?
I am currently using PyCharm 3.1 (EAP).

Currently the only possibility is to use the "Before launch | Show this page" option.

I've found today that now is possible to ask for parameters using the "Prompt" macro on the "Run configuration" parameters field.
https://www.jetbrains.com/help/pycharm/code-running-assistance-tutorial.html#parameter-with-macros

Although yole's answer is the de facto way to be prompted for thw arguments before running a program, it is slightly annoying because:
the dialog is visually overwhelming and cluttered instead of focused on what you want to do;
you have to tab to reach the arguments field if you want to use the keyboard exclusively (and why not?);
Nothing you could do about that. (Except maybe file a ticket. Have you done that?)
I'm just adding what I used to do before I knew about Googled for this option for the sake of completeness (obvously, this is a hack in the least glamorous sense of the term). But it did suit my workflow as I often only had discrete lines to test with, and didn't switch that often.
Create a new configuration set to the same file, but with a special 'magic' parameter;
Add code to your script to check if the magic is there;
Use a string variable instead of sys.argv (pass it through lambda args: [__name__] + args.split() to reduce the boilerplate);
???
Profit;

I'm doing this on a Mac, but hopefully this will be helpful for Windows or Linux.
Go to Run > Edit Configurations
There will be a dialog box that opens.
Script: file you want to run (ending with .py)
Script Parameters: the command line arguments
Working Directory: directory where your project is.

My simple answer is adding another wrapper as the cover in the source code which will run on the selection you made through code branch or external command or file, so choosing different branch is just a 'ddp' tap distance in vim(line change for parameter settings). You dont have to depend on pycharm updating by building your own code world:)

Is there a way to share common configuration using Paste Deploy?

This is a pretty simple idea conceptually. In terms of specifics, I'm working with a pretty generic Kotti installation, where I'm customizing some pages / templates.
Much of my configuration is shared between a production and development server. Currently, these settings are included in two separate ini files. It would be nice to DRY this configuration, with common settings in one place.
I'm quite open to this happening in python or an an ini file / section (or perhaps a third, yet-to-be-considered place). I think it's equivalent to use a [DEFAULT] section, or pass dictionaries to loadapp via global_conf, but that seems to be processed in a squirrelly way. For example, Kotti thinks I've properly set sqlalchemy.url, but sqlalchemy iteself fails on url = opts.pop('url'). Moreover, since Kotti defines some default settings, Paste doesn't end up searching for them in the global_conf (e.g., kotti_configurators).
I don't like the idea of passing in a large dict for %(var)s substitution, as it requires effectively renaming all of the shared variables.
In my initial experiments with Paste Deploy, it demands a "main" section in each ini file. So, I don't think I can just use a use = config:shared.ini line. But that's conceptually close to what I'd like to do.
Is there a way to explicitly (and properly) include settings from DEFAULT or global_conf? Or perhaps do this programmatically with python on the results of loadapp?

For example, Kotti thinks I've properly set sqlalchemy.url, but sqlalchemy iteself fails on url = opts.pop('url').
If you think something is odd and you're asking on SO it'd be wise to show a stacktrace and an example of what you tried to do.
Kotti gets its settings the same as any pyramid app. Your entry point (def main(global_conf, **settings) usually) is passed the global_conf and settings dictionary. You're then responsible for fixing that up and shuffling it off into the configurator.
For various reasons PasteDeploy keeps the global_conf separate from the settings, thus you're responsible for merging them if you wish.
[DEFAULT]
foo = bar
[app:main]
use = egg:myapp#main
baz = xyz
def main(global_conf, **app_settings):
settings = global_conf
settings.update(app_settings)
config = Configurator(settings=settings)
config.include('kotti')
return config.make_wsgi_app()

How to store application settings across modules [duplicate]

This question already has answers here:
How to save application settings in a config file?
(3 answers)
Closed 9 years ago.
I received a project from developer who left our company. Not too complex, but it doesn't look very nice.
So here is the question:
Application has some modules and one is "settings" which stores some app. options (not all possible options, lets say just two: foo and bar).
When application is started it reads options from command line (using argparse):
parser.add_argument('--foo', action='store_true')
parser.add_argument('--bar', action='store_true')
parser.add_argument('--baz', action='store_true')
And then it performs this nasty thing:
for name, val in parser.parse_args(sys.argv[1:])._get_kwargs():
setattr(sys.modules['settings'], name, val)
First: I think this is dirty, non-pythonic hack. And second, it is simply inconvenient to use such code, because when I need to use settings.baz, IDE complaints that it doesn't exist.
The intention of this hack is to make options parsed from command line available in all modules that are used in application further.
I'm thinking about something like singleton pattern, but I only used it once in PHP, and don't know if this correct solution in python. And even if it is, can someone show example?
I'm noob in python and on SO, please be kind to me :)
Thanks.
p.s. I'm sorry for possible mistakes in my English

Modules in Python are singleton objects, and using one to store the settings used by the other modules would be a very Pythonic
The second line of the "nasty thing" is just setting the attributes of a module named settings and so isn't that bad. What's worse is the _get_kwargs() part of the first line which is accessing a private attribute of the argparse.Namespace object returned by parser.parse_args() to get the names and values of the settings parsed from the command-line. A slightly better way to do it might be something like this:
import settings # possibly empty .py file
for name, val in vars(parser.parse_args(sys.argv[1:])).iteritems():
setattr(settings, name, val)
However this won't fix your IDE problems because the IDE doesn't know the name of settings added dynamically. A simple way to fix that would be to define all the possible attributes with some kind of default values in a settings.py module instead of having an empty one.
The first time a module is imported an entry for it is added to the sys.modules dictionary with its name as the key and an instance of types.ModuleType as a value. Subsequent imports will first check to see if an entry for it already exists and will skip reloading the file if it does -- which is why I claim they're basically singleton objects. Modifications made to its attributes will immediately be visible to other modules that have imported it or do so afterwards, so it's generally a good data sharing mechanism within an application.

Look this Config (A hierarchical, easy-to-use, powerful configuration module for Python )
Detailed doc & examples