61–70 of 86 posts
Earlier quoted context omitted.
I just can't get to use some modules within virtualenv. They seem to create more problems than using systemwide.
Which ones? You can get some help. Learning virtualenv is a smart long-term move
Earlier quoted context omitted.
I just can't get to use some modules within virtualenv. They seem to create more problems than using systemwide.
Which ones? You can get some help. Learning virtualenv is a smart long-term move
Earlier quoted context omitted.
from __future__ import print_function
That's a side effect, right? Your module after the import is not the same as it was before, or am I missing something?
Earlier quoted context omitted.
Not me either anymore. I tried to port to introspection + Gtk3 but ran into problems with widget subclasses and no documentation to resolve it with.
I only extensively used it from Perl and Vala, but with GObject-Introspection I tend to more often look at the original library documentation than something language specific. This can be a disadvantage at first, but for me it turned out more convenient, since GIR-inflated bindings can be more complete, as long as the inflation supports the features the API describes. They also tend to be more consistent in their dif…
Earlier quoted context omitted.
> I once used a Ruby library that, when loaded, would try to connect to a database on a remote machine. How is that at all acceptable? I can't believe that a library that phones home would gain any sort of popularity. I can't say I know much of anything about the Ruby community, but if they've conditioned you to jump through hoops like importing modules at specific times to avoid delays, that is a serious problem. Co…
install my module! Also.. trust me because it's totally safe. curl http://foo.com/tBrwn | bash http://rvm.io/rvm/install
It's explicitly user space software, and unprivileged user space software at that, so having it require admin interaction (i.e. touching the system package manager) to install seems like a sledgehammer where a flyswatter would do.
They could use a VCS repo of some kind, but that doesn't handle the various folder and script installs that need to happen - and also doesn't help if there isn't that specific VCS on the system.
Upstream security is less of a concern since that hotlink just points to raw code on Github, and over HTTPS no less.
So what are the negatives here? For software like RVM, this seems like the best, most portable solution that works for the most people.
IMHO, the way to go here instead is dependency injection:
Inject the configuration into the module through a function or class method (e.g. Flask.initialize({config state}). Wrapping all module functionality that depends on configuration in a class is a good idea here since it allows you to use multiple configurations in parallel and makes your code more modular.
As an example, in BlitzDB (a document-oriented database for Python, https://github.com/adewes/blitzdb) there is no global configuration at all, so you can initialize and use multiple backends in parallel as you please without worrying about side effects. SQLAlchemy does it in a similar way btw.
Would anyone like to share their experiences avoiding this sort of problem in the context of web frameworks and building the back end for larger web sites/apps? As an example for discussion, the first time I wrote a Flask-based back-end, I backed myself into a corner almost immediately in the following way. Firstly, the WSGI file that the web server uses to start the application followed the suggestion in the Flask d…
def app_factory(config):
app = Flask("yourapplication")
app.config.from_pyfile(config)
# ...
return app
from flask import current_app as app
@app.route('/')
def home_page():
# ...
def app_factory(config):
# ...
app.route('/')(somemodule.home_page)
# ...
from flask import current_app as app
from myfoo import app_factory
import unittest
class MyFooTest(unittest.TestCase):
# ...
if __name__ == '__main__'
test_app = app_factory(test_config)
# The app proxy will point to that inside test cases
unittest.main()
Putting side effects in the __init__ code seems to become quite fashionable these days but is a pretty bad idea since it removes the possibility to "just" import the functionality defined by the module without performing any initialization. Personally, I always try to avoid having a system that relies on some global configuration (like e.g. Django, Matplotlib or Flask do). In matplotlib for example this causes a lot…
Earlier quoted context omitted.
from __future__ import print_function
As I understand it, "from __future__ import ..." statements are actually a special type of statement that doesn't actually import a module at all - they just use similar syntax for compatibility reasons. There is an actual __future__ module, also for compatibility reasons, but importing it has no side-effects.