|
Addict posted:So is everyone using the .96 release of django or the latest on subversion. When looking to extending the admin panel they keep saying they want to overhaul it with newforms and such. It seems like a few things are in limbo at the moment. I have been sticking to .96. You should always use trunk, since that's what gets bug fixes and new features. They still reserve the right to break APIs, but that rarely happens now, and it's always thoroughly documented. The version releases are just for crazy people who value "feature stability" over everything else.
|
#
¿
Mar 29, 2008 17:42
|
|
|
|
| # ¿ Apr 28, 2024 01:41 |
|
|
deimos posted:Gah, this is a pet peeve of mine, it's a bit wasteful and IMO makes it harder to read when you have a single method that does both: self.cleaned_data.get('bool_field', False) works fine to replace both of those. Even better, just .get('foo'). It'll return None when the key doesn't exist, which evaluates to False in a boolean context. I'd be more concerned about his tabs for indentation, which is definitely not part of any accepted Python coding standard or style guideline that I've ever heard of or seen before (the official Python style guide specifies 4 spaces for tabs). The if not ... in ... is also kind of hard to read. I'd use if ... not in ... 
|
|
#
¿
May 15, 2008 03:48
|
|
|
Wulfeh posted:for the: if not ... in ... and the if ... not in ... is that just a preference of yours, or do most Python developers try to strive for the latter? (it's like asking "if there isn't this field in the cleaned data", or "if the field isn't in the cleaned data") I'd use not in because it reads more like English. It's just easier for me to read, that's all. Using not in reads to me like both of your examples, whereas using not ... in ... makes me pause for a second to think about it. It's obviously not a huge deal, but readability is a pretty important tenet of Python, so I guess I notice these things more than in other languages.
|
|
#
¿
May 15, 2008 05:32
|
|
|
Bonus posted:Haha! Nice. Not really. For deployment situations you should deploy it using distutils like any other Python package. If you want to do development without installing it you can add it to your PYTHONPATH. If you're one insane crazy dude and you're trying to target multiple versions of Django across apps, you should insert them into sys.path with your runner/WSGI scripts.
|
|
#
¿
Jul 1, 2008 00:47
|
|
|
I would recommend that you stop worrying about every minute detail of your implementation and just start coding. Django isn't as in your face as Zope: you don't have to declare everything up front, you don't have to battle with the Zope server when you're editing live code and adding files, you can completely blow away your database and start over if you don't like something. Try not to think about the framework, but think about what you're trying to solve. As you code you should begin to see what will work and what won't work. Of course, you should still think about how you generally want to solve a problem before you tackle it, but Django makes it easy to do things in a more iterative fashion. I'd also recommend that you just stop thinking about Zope. Try not to think, "well, I know I'd do this in Zope like this." I know this can be hard when you have little context, but I think as you read documentation and read other people's code you'll get an idea of how people do things in Django - and how they don't do them. There's a lot of open source Django code available on the web, so you could actually see what specific things people did to solve problems similar to the ones you're working on. I'd recommend checking out some of the links on the DjangoResources wiki page.
|
|
#
¿
Jul 2, 2008 01:12
|
|
|
ATLbeer posted:Has anyone looked at deploying Django with mod_wsgi instead of mod_python. I've heard there are some performance benefits over mod_python but, it looks like you might have to hack your code base a bit to make it compatible. I've googled but, it's a bit sparse. I've set up Django with mod_wsgi in production environments, I haven't had any problems with it. There is one longstanding issue with Django's WSGI support involving PATH_INFO, but that can be worked around, and the mod_wsgi site has great documentation, including how to deal with Django specifically. mod_python is a huge piece of poo poo. It's a poorly designed framework around Apache, and you can only use it within Apache. Django abstracts it all away, but personally having dealt with it directly on many occasions, I could never see myself going back to it. I think mod_wsgi is the way to go.
|
|
#
¿
Jul 8, 2008 22:39
|
|
|
bitprophet posted:I'd be honestly interested to hear more on this -- not saying I don't believe you (it's semi well known that, maturity aside, mod_wsgi is a superior approach) but the only material I've seen repeatedly is that mod_python is simply not as efficient and/or layered as the WSGI approach. Like I said, my beef with it stems from experience with using it directly, i.e. without a framework abstracting it out of the way. When you have a system developed only for mod_python, you can only develop applications on mod_python. This makes any kind of development a huge pain because you can't do it outside of mod_python and Apache, and its code reloading isn't really predictable and doesn't work for applications installed into site-packages. When you're using it from Django this isn't really an issue, because someone did all the hard work for you already, and you don't have to do development on mod_python. The performance differences between the two modules are basically irrelevant, and I'm not sure what you mean by more "layered." WSGI is a great specification. It doesn't tie you down to any one web server, you can use whatever WSGI server you like. mod_python predates WSGI - it's archaic and unwieldy in comparison now. The author of mod_wsgi delineates some specific differences between the two modules in this mailing list post. Among more practical differences is the ability to reload specific Python applications (by updating the modification date of a WSGI script file) and the extensive options for setting resource limits on Python processes (e.g. you can reload the processes after N requests, or reload them after N seconds idle time, etc.). I also foresee the Python community moving toward mod_wsgi because of all of these reasons, and because it's still actively developed and specifically designed for a much wider array of use cases (e.g. in shared hosting environments). Other options include FastCGI/SCGI and flup, but I personally don't use flup anymore because I ran into issues with it timing out long running HTTP connections (where this wasn't an issue with other platforms). It doesn't help that flup isn't really maintained anymore, and the author hasn't responded to my bug reports. There's also no community around it, as far as I can tell.
|
|
#
¿
Jul 9, 2008 01:10
|
|
|
Grey Area posted:Using the standard csv module would be more robust. I don't think it handles what he's talking about by default, but he could use a custom dialect/writer like this: http://www.djangosnippets.org/snippets/993/
|
|
#
¿
Aug 26, 2008 01:27
|
|
|
dimebag dinkman posted:The Django docs make a big deal out of the fact that you shouldn't serve static files through Django. That makes sense, but what if I want to only allow the download of a large static file for people authenticated and in a certain group etc.? Is there actually any satisfactory way of having Django handle a request initially, and then have it pass control over the fastest method available to send a static file? (I'm using lighttpd + FastCGI, currently.) deimos obnoxiously alluded to it: X-Sendfile. Enable that in your mod_fastcgi settings and when your application sends an X-Sendfile header, lighttpd will discard your application's response and serve up the file the header specifies. I believe it just needs to be an absolute path. Be sure to set the Content-Type on the response though, as I don't think lighttpd does it for you in this case. It does set the Content-Length itself, however. There's also an Apache module for X-Sendfile support called mod_xsendfile.
|
|
#
¿
Sep 30, 2008 04:23
|
|
|
Mashi posted:When using mod_wsgi in daemon mode with apache, should i feel comfortable running multiple threads? I don't know how to check my application for thread safety any further than just doing a bit of stress testing and seeing if it falls over. It's a basic database driven Django site without any special 3rd party modules. The threads can't share anything, so you shouldn't have a problem. The option is available more as a matter of performance. The only time I could imagine it being an issue is if you're using a C extension that isn't coded properly. Issues with concurrent access to shared resources outside of Python would also present themselves using multiple processes, so you should keep that in mind if you're doing anything like that (e.g., modifying files, in which case you'd use file locks). I haven't had any issues doing this with Django and MySQLdb.
|
|
#
¿
Mar 8, 2009 04:51
|
|
|
|
| # ¿ Apr 28, 2024 01:41 |
|
|
I usually run my own local sqlite database, and make sure there are fixtures for whatever data we'd all need up front to do development/testing. I can't really imagine doing it any other way, but I haven't looked at anything like South yet. That said, we also have a central staging server for potential releases that anyone can request their code be pushed to. This is more for testing than development, though, and sometimes clients will have access to this as well.
|
|
#
¿
Apr 11, 2010 23:05
|
|