Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I want to understand how global variables are implemented in web2py web framework.
I assume that a reader knows the structure of web2py app.
I don't understand how come variable db is available in every controller .py file without any import statement.
I found that it db is created in models/db.py and it is bonded to current.db.
How db is made globally available without any import.
Thank you!
This is right there in the docs:
Models, controllers, and views are executed in an environment where the following objects are already imported for us:
(That's the reference docs; the tutorial says effectively the same thing, but without the complete list of everything that's imported.)
If you want to know how that works, the basic concept simple: web2py doesn't just run your web app as a standalone script; it loads and executes your code the way it wants to. If you want full details, see the source. (From compileapp.py, it looks like they're part-way through publicly exposing the interfaces for loading applications and their components with an environment, but haven't gotten there yet.)
If you want to know different ways you could do something similar, there are two basic ways.
The hacky solution is to skip import entirely, and use exec to run the code within a custom globals. (Slightly better, you can compile the file (even using the standard .pyc caching mechanism if you want), and then exec the resulting code object.) This makes sense if you want to run the module directly in the top level namespace, or if you need more isolation than modules can give you and plan to build it yourself. But usually it's not what you want.
The other solution is to intercept part of the import process. For simple cases, it's just a matter of calling __import__ with a custom globals.
But a framework that's doing this often needs to customize a lot more. Python 3.3+ makes this relatively easily; if you want to be compatible with a wide range of Python versions, you end up rewriting large chunks of the import process yourself, which I'm guessing is what web2py does.
In web2py, model files are executed in an environment that has been populated with many of the framework API objects. The controller is then executed in that same environment after the model files have run, so any objects created in the models will be available in the controller (and the view).
For more details, check out the Workflow section in the book and the end of the Dispatching section.
Note, items such as db that are defined in a model file are not added to the current thread local object by web2py, though you can explicitly add them yourself in the app code.
Related
I currently have two files: control.py and list.py. list.py contains a list of objects that I want to access and edit in control.py. In the project I'm working on, I should be able to open multiple instances of control.py (essentially, open x number of terminals each running its own instance of control.py). I want to able to access the list in list.py from each instance of control.py. Each instance should be able to edit the list such that after editing, all the other instances should be able to see the edited list.
I've looked into the shelve module but it turns out that shelve doesn't support concurrent modification, so that won't work because i need each instance to simultaneously be able to read and edit the list.
The usual solution to this problem is known as "pubsub"; i.e., publish/subscribe. See https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern for a primer on the topic. There is no way to do this using just the capabilities provided by the core Python libraries; at least not without writing a pubsub implementation using those capabilities.
However, I get the sense you are doing the programming equivalent of trying to use a hammer to drive a screw. That is, because a hammer is the only tool you know how to use every problem looks like a nail. Reframing the problem is likely to help you, and us, provide better solutions.
Concept of this question is to gather information on how you would
proceed to gather information about whether a function and/or class is
in use in the entirety of an application.
Background information
The application is 3-5 years old, based originally on Python 2.4 (Upgraded over the years to latest Python 2.7.11), Django 1.0 (Upgraded over the years to 1.4.22), some custom frameworks which implement some ruby on rails magic (Create a controller file with function names and they turn into an HTTP endpoint, functions with _ infront will not be visible to the enduser), total number of endpoints, derived from django.url* tells me I have to manually create 100 endpoints for various needs and purpose. Number of Django apps/modules is around 20, they are entangled into each other, and I know not all are used, but heres the thing, how would I proceed to gather information to tell which function are used or not? So I could do a refactoring of the code, to reduce noise?
I've used PyCharm and its intelligence but based on how the application and how Python works, some of the suggestion are making the application not working.
Example of above: some functions in models, and views are not using self and then PyCharm thinks 'well this function can be changed to a static method' but somewhere else in the code the previous developer use self."function_name" and by using that call it actually imply "Please provide me with self and the argument".
TLDR: How to proceed to weed out dead and not used code in an easy and efficient way? Thanks for all input in advance.
I am creating an application consisting of several modules. There is one main.py file which will be the file to run the application. The main.py file will load the configuration file(s) and put them in the 'config'-variable. It will also import the application-module-file (the file which holds the source-code of the application itself, a.k.a. application-class) and start the instance.
I am not very experienced in coding Python, and my biggest question is if I am doing it the right way, by using a main-file to handle all needed stuff (loading configuration-files for example). The problem I am having right now is that I cannot access the 'config'-variable that was defined in the main.py-file from any other module and/or Python-file.
Is it possible to make a global variable for configuration-values exc.? I know in PHP I used to create a singleton object which holds all the specific global arguments. I could also create a global 'ROOT'-variable to hold the full path to the root of the application, which is needed to load/import new files, this is also not possible in Python as far as I know.
I hope someone can help me out of this or send me in the right direction so I can continue working on this project.
The answer seems to be by Matthias:
Use from AppName.modules import settings and then access the data in the module with settings.value. According to PEP-8, the style guide for Python code, wildcard imports should be avoided and would in fact lead to undesirable behaviour in this case.
Thanks you all for the help!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Over time I found the need to override several stdlib methods from Python in order to overcome limitation or to add some missing functionality.
In all cases I added a wrapper function and replaced the original method from the module with my wrapper (the wrapper was calling the original method).
Why I did this? Just to be sure that all the calls to the method are using my new versions, even if these are called from other third-party modules.
I know that monkeypatching can be a bad thing but my question is if this is useful if you use it with care? Meaning that:
you still call the original methods, assuring that you are not missing anything when the original module is updated
you are not changing the original "meaning" of the methods
Examples:
add coloring support to python logging module.
make open() be able to recognize Unicode BOM masks when using text mode
adding logging support to os.system() or subprocess.Popen() - letting you output to console or/and redirect to another file.
implementing methods that are missing on your platform like os.chown() or os.lchown() that are missing on Windows.
Doing things like these appear to me as decent overrides but I would like to see how others are seeing them and specially what should be considered as an acceptable monkeypatch and what not.
None of these things seem to require monkeypatching. All of them seem to have better, more robust and reliable solutions.
Adding a logging handler is easy. No monkeypatch.
Fixing open is done this way.
from io import open
That was easy. No patch.
Logging to os.system()? I'd think that a simple "wrapper" function would be far better than a complex patch. Further, I'd use subprocess.Popen, since that's the recommended replacement.
Adding missing methods to mask OS differences (like os.chown()) seems like a better use for try/except. But that's just me. I like explicit rather than implicit.
On balance, I still can't see a good reason for monkeypatching.
I'd hate to be locked in to legacy code (like os.system) because I was too dependent on my monkeypatches.
The concept of "subclass" applies to modules as well as classes. You can easily write your own modules which (a) import and (b) extend existing modules. You then use your new modules because they provided extra features. You don't need to monkeypatch.
even if these are called from other third-party modules
Dreadful idea. You can easily break another module by altering built-in features. If you have read the other module and are sure the monkeypatches won't break then what you've found is this.
The "other" module should have had room for customization. It should have had a place for a "dependency injection" or Strategy design pattern. Good thinking.
Once you've found this, the "other" module can be fixed to allow this customization. It may be as simple as a documentation change explaining how to modify an object. It may be an additional
parameter for construction to insert your customization.
You can then provide the revised module to the authors to see if they'll support your small update to their module. Many classes can use extra help supporting a "dependency injection" or Strategy design for extensions.
If you have not read the other module and are not sure your monkeypatches work... well... we still have hope that the monkeypatches don't break anything.
Monkeypatching can be "the least of evils", sometimes -- mostly, when you need to test code which uses a subsystem that is not well designed for testability (doesn't support dependency injection &c). In those cases you will be monkeypatching (very temporarily, fortunately) in your test harness, and almost invariably monkeypatching with mocks or fakes for the purpose of isolating tests (i.e., making them unit tests, rather than integration tests).
This "bad but could be worse" use case does not appear to apply to your examples -- they can all be better architected by editing the application level code to call your appropriate wrapper functions (say myos.chown rather than the bare os.chown, for example) and putting your wrapper functions in your own intermediate modules (such as myown) that stand between the application level code and the standard library (or third-party extensions that you are thus wrapping -- there's nothing special about the standard library in this respect).
One problematic situation might arise when the "application level code" isn't really under your control -- it's a third party subsystem that you'd rather not modify. Nevertheless, I have found that in such situations modifying the third party subsystem to call wrappers (rather than the standard library functions directly) is way more productive in the long run -- then of course you submit the change to the maintainers of the third party subsystem in question, they roll your change into their subsystem's next release, and life gets better for everybody (you included, since once your changes are accepted they'll get routinely maintained and tested by others!-).
(As a side note, such wrappers may also be worth submitting as diffs to the standard library, but that is a different case since the standard library evolves very very slowly and cautiously, and in particular on the Python 2 line will never evolve any longer, since 2.7 is the last of that line and it's feature-frozen).
Of course, all of this presupposes an open-source culture. If for some mysterious reasons you're using a closed-source third party subsystem, therefore one which you cannot possibly maintain, then you are in another situation where monkey patching may be the lesser evil (but that's just because the evil of losing strategic control of your development by trusting in code you can't possibly maintain is such a bigger evil in itself;-). I've never found myself in this situation with a third-party package that was both closed-source and itself written in Python (if the latter condition doesn't hold your monkeypatches would do you no good;-).
Note that here the working definition of "closed-source" is really very strict: for example, even Microsoft 12+ years ago distributed sources of libraries such as MFC with Visual C++ (as their product was then called) -- closed-source because you couldn't redistribute their sources, but still, you DID have sources at hand, so when you met some terrible limitation or bug you COULD fix it (and submit the change to them for a future release, as well as publishing your change as a diff as long as it included absolutely none of their copyrighted code -- not trivial, but feasible).
Monkeypatching well beyond the strict confines within which such an approach is "the least of evil" is a frequent mistake of users of dynamic languages -- be careful not to fall into that trap yourself!
I'm setting up a web application to use IronPython for scripting various user actions and I'll be exposing various business objects ready for accessing by the script. I want to make it impossible for the user to import the CLR or other assemblies in order to keep the script's capabilities simple and restricted to the functionality I expose in my business objects.
How do I prevent the CLR and other assemblies/modules from being imported?
This would prevent imports of both python modules and .Net objects so may not be what you want. (I'm relatively new to Python so I might be missing some things as well):
Setup the environment.
Import anything you need the user to have access to.
Either prepend to their script or execute:
__builtins__.__import__ = None #Stops imports working
reload = None #Stops reloading working (specifically stops them reloading builtins
#giving back an unbroken __import___!
then execute their script.
You'll have to search the script for the imports you don't want them to use, and reject the script in toto if it contains any of them.
Basically, just reject the script if it contains Assembly.Load, import or AddReference.
You might want to implement the protection using Microsoft's Code Access Security. I myself am not fully aware of its workings (or how to make it work with IPy), but its something which I feel you should consider.
There's a discussion thread on the IPy mailing list which you might want to look at. The question asked is similar to yours.
If you'd like to disable certain built-in modules I'd suggest filing a feature request over at ironpython.codeplex.com. This should be an easy enough thing to implement.
Otherwise you could simply look at either Importer.cs and disallow the import there or you could simply delete ClrModule.cs from IronPython and re-build (and potentially remove any references to it).
In case anyone comes across this thread from google still (like i did)
I managed to disable 'import clr' in python scripts by commenting out the line
//[assembly: PythonModule("clr", typeof(IronPython.Runtime.ClrModule))]
in ClrModule.cs, but i'm not convinced this is a full solution to preventing unwanted access, since you will still need to override things like the file builtin.