Thanks, this is great advice. easy_install comes preinstalled on a Mac, which is where the confusion arose. Will update the article when I get a chance.
5,979 karma · joined May 28, 2010
The activate/deactivate magic is responsible for some real nastiness in deployment scripts, and total confusion for beginners who are thrown by the statefulness. Virtualenvwrapper makes the situation even worse by hiding the virtual environments away.
By far the easiest way to use virtualenv is to forget about activation completely, and directly reference the binary you want to use. For example, rather than typing:
source env/bin/activate
python myprogram.py
env/bin/python myprogram.py
I have no doubt that if I dug into it then it would all make sense, but my first instinct is this: how much of this complexity (proxy objects to thread locals, context stacks etc) results from the fact that doing:
from flask import request
Perhaps things would be easier if instead of:
from flask import request
...
@app.route('/'):
def index():
return "Hello from %s" % request.args.get('name')
@app.route('/'):
def index(request):
return "Hello from %s" % request.args.get('name')
I'd argue that's a documentation issue. QuerySet is Django's abstraction of a set of filterable database results. Keeping this conceptually separate from other parts of the ORM, such as the model class, is valuable IMO, and I'm not sure we gain much by trying to hide the details. One of the things I love about Django's philosophy is that it generally provides shortcuts that encapsulate common patterns without obscuring them.
There's a fine line between discussing the minutiae of API design and bikeshedding, and I think that anything Django can do to help here is valuable, so I won't push the issue any further. Let's pick it up again on the mailing list or Trac at an appropriate time.
I think my main objection is that these query methods should conceptually be on the QuerySet, and so defining them on the Manager (the "wrong place") and magically copying them to the QuerySet (the "right place") feels somehow worse than the opposite.
I appreciate that you raised the discussion on the mailing list, as it highlights the fact that this is a common problem in big Django codebases. Even pulling something like PassThroughManager into core might work (perhaps with a nicer "manager_with_queryset" API, as suggested by Aramgutang).
DabApps is looking for a junior to mid-level software developer with minimum one year of experience. May suit graduate with internship or sandwich year experience.
DabApps is a growing company based in the centre of Brighton. We concentrate on web and mobile application development, and are passionate about producing high-quality work that we and our clients can be proud of. Our values are based on standards compliance and best practice and we are constantly working to improve and streamline our development process. We use open source technology wherever we can, and contribute back to the open source community as much as possible.
Below is a list of core technologies and skills we are looking for. We are not expecting any candidate to have experience or knowledge in all of these areas. What we are looking for is the ability and desire to learn in a self-motivated way to fill in the gaps in your knowledge as required.
Python, Django, Objective-C, JavaScript, HTML/CSS, Relational databases, Redis, MongoDB, CouchDB or other NoSQL databases, Solr, ElasticSearch or other search solutions, "Big Data", distributed systems, data analysis/indexing, Linux server administration, Mac or Linux desktop experience, User experience analysis and design, prototyping
See http://dabapps.com/careers/current-vacancies/2012-04-softwar... for full details.
j = 10 -- global variable
local i = 1 -- local variable
Same with functions. To declare a function that is restricted to the local scope, you must explicitly use "local":
local f = function (...)
...
end
I can't see the license specified anywhere, any chance you could add a LICENSE file or similar?
The `mezzanine-project myproject` bootstrapping command should be just an optional shortcut for projects which are completely CMS-based. Which, in my experience, is the minority of projects.
I built a template library for Django on top of it: https://github.com/j4mie/django-spurl
# 1. Matrix multiplication
m1 = matrix([1, 2, 5],
[2, -1, 6],
[5, 10, -1])
m2 = matrix([2, 3, 1],
[-3, -1, -3],
[4, 9, -2])
show m1 * m2
This could be useful if I've embedded a player with embed.ly and then want to control it from elsewhere on the page (say, have a big "play" button somewhere).
* automatic browsable self-documenting HTML output when you hit the API in a browser [1]
* the fact that django-rest-framework uses as much of Django 1.3's class-based view infrastructure as possible, and so fits better with the way Django works.
[1] example: http://api.django-rest-framework.org/
For me it's ambient and/or electronic (particularly Brian Eno) or occasionally a bit of folk or indie.
Anyone know what replaces this?
How would I write this (stupid code that would eventually blow the stack) without arguments.callee?
(function () {
console.log("hello world");
setTimeout(arguments.callee, 1000);
})();Some developers prefer Python, some prefer Ruby. An individual developer might be able to reel off a list of reasons why one is better than the other, but in the end it comes down to something intangible and subjective - "Ruby just feels better" or "Python fits my brain better".
The concept of "magic" is very similar. What feels magical and opaque to one developer might be plain and obvious to another. When you ask what "magic" means, you'll get different answers from different people.
From my point of view (as a Python/Django developer), even the basic commands that Rails uses feel strange. Compare the very first line of code that you run in a Django project vs a Rails project:
django-admin.py startproject mysite
rails new blog
The latter says: "run the command rails" (what is this? A Ruby script? A bash script? A binary? Why is it called "rails" when the whole framework is called "Rails"?) and pass the arguments "new blog" (obviously this is creating something, but what? In most languages, "new" is a keyword that is usually used to create instances of classes - so is it creating an instance of something called "blog"? Does that mean that Rails knows what a "blog" is already?) To me - this is magic. Rails says "type this incantation and I'll do some stuff for you". Django says "here are some tools you can use to do stuff".
You might disagree with me entirely in this particular case - perhaps you find the Rails example clearer - which is fine. The point of this example is to say that framework and language preference is so intangible that the very first line of your documentation can sway someone's opinion either way. Instead of fighting against the "magic myth", you should just be trying to attract developers who like your particular brand of magic (or, alternatively, don't see your code as magic at all).
It would be nice if this was separated out into "old-fashioned" AI (data mining, statistical inference, machine learning, etc) and bio-inspired technologies (genetic algorithms, cellular automata, neural networks - although the latter may be a grey area).
Alternatively, a better name than "Artificial Intelligence" should have been used for the site. Probably too late now though..
If I write a paper describing an algorithm (or process, or simulation, etc) and open source my code, someone attempting to reproduce and confirm my work is likely to take my code, run it, and (obviously) find that it agrees with my published results. No confirmation has actually taken place - errors in the code will only confirm errors in the results. Further work may then be based on this code, which will result in compound errors.
If, however, I carefully describe my algorithm and its purpose in my paper, but don't open source the code, anyone who wishes to reproduce my results will have to re-implement my code, based on my description. This is vastly more likely to highlight any bugs in my implementation and will therefore be more effective in confirming or disconfirming my findings.
I'm not sure yet what I think about this argument. It seems to only apply in certain domains and within a limited scope (what if the bug exists in my operating system? Or my math library?) but in relatively simple simulation models, it may have some validity.
What do you think?
[1] From Adrian Thompson, if you're interested: http://www.informatics.sussex.ac.uk/users/adrianth/ade.html