Re: How to get DATABASE_NAME
On 16/08/09 09:38, Maksymus007 wrote: > On Sun, Aug 16, 2009 at 10:30 AM, adelaide_mike > wrote: >> In my reporting function I need to have: >> >> If DATABASE_NAME = x: >>#do this >> Else: >>#do the other >> >> How can I obtain that name, which is established in settings.py? >> >> Mike > import myproject.settings; > > if settings.DATABASE_NAME = x: > Slight clarification required here. Best practice is to use: > from django.conf import settings for your import as it will contain the defaults not defined in myproject.settings, along with other good reasons. See http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-in-python-code for more information. Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: with statements
On 16/08/09 09:50, GuyBowden wrote:
> Hi All,
>
> Just wondering what the best way to do this sort of thing is:
>
> {% with last_tweet_sent this_user as sent_at %}
> {{ sent_at|naturalday:_("MONTH_DAY_FORMAT")|capfirst}}
> {% endwith %}
>
> I've got a function "last_tweet_sent" in a templatetags module that
> takes a user and spits back the last time they sent a tweet.
>
> I'd like to keep the formatting of the date in the template rather
> than in the templatetag module (best practice?)
>
> But I can't use the with statement to put the result of my function
> call in a variable - I guess because of the spacing there for calling
> the function with an argument.
>
> Any suggestions?
>
> Cheers,
>
> Guy
>
Just to clarify, is your last_tweet_sent a template tag or a template
filter? In the first instance you won't be able to do what you want, and
it's probably overkill. In the second instance you should be able to do:
> {% with this_user|last_tweet_sent as sent_at %}
> {{ sent_at|naturalday:_("MONTH_DAY_FORMAT")|capfirst}}
> {% endwith %}
The template fitler definition would look something like this:
> @register.filter(name='last_tweet_sent')
> def last_tweet_sent(user):
> # work out when it was and call it dt
> return dt
The alternative is to make it a method on the user object, but that requires a
bit more fu in replacing the User model with a custom one. From what I
remember, [1] is the place that tells you how to do it. Again, this method is
probably overkill ;-).
Alex
[1] http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Class-based views, metaclasses and view validation
creation in Python. First, the class statement executes all the code in the class body, using the newly bound objects (mostly the methods) to populate a dictionary. This dictionary is then passed to the __new__ method on the metaclass, along with the name of the class and its base classes. Unless otherwise specified, the metaclass will be type, but the __metaclass__ attribute is used to override this. The __new__ method can alter the name, base classes and attribute dictionary as it sees fit. In our case we are wrapping the functions in class method constructors so that they do not become instance methods. Other things we could do are: * Override handle_DELETE in a subclass to call cls.method_not_acceptable if the cheese is important (calling super(cls, cls).handle_DELETE if it isn't) * Despatch to other methods from a handler to keep our code looking modular and tidy * Subclass __new__ to add more parameters to the handlers on subclasses As an example of the last point, we have an OAuthView that ensures an access token for a service and adds an urllib2 opener to the parameters which contains the necessary credentials to access a remote resource. The subclassing view can then simply call opener.open(url) without having to worry about achieving the requisite authorisation. Using class-based views allows us to define other methods on the views to return metadata about the resource being requested. As an example, we have a method that constructs the content for the breadcrumb trail, and another that returns the metadata for displaying in search results. Achieving such extensibility with function-based views would be nigh on impossible. Now for view validation... As you may have noticed, all these methods (handle_foo, initial_context) have similar signatures. To make sure they're consistent we have a test that looks through all the installed apps looking for classes that subclass BaseView. It then uses inspect.getargspec to compare the signatures. The alternative to this would be to check them in the metaclass, and raise an appropriate error at class creation time. Hopefully you find this useful[1]. We'd be very grateful to hear any suggestions or criticisms that you may have. I certainly don't suggest this approach is applicable in every case, but it's helped us to adhere as much as possible to the DRY principle. My only concern is that with such levels of indirection and 'advanced features', it may be a little daunting for any new developers -- I didn't know anything about metaclasses or how method binding actually works until yesterday. Yours, Alex [0] Simon Willison seems to talk about them occasionally, though searching Google for 'class-based views' doesn't turn up much. [1] If all goes well, I'll make a blog post of this. -- Alexander Dutton Erewhon Project Officer | m.ox.ac.uk developer Oxford University Computing Services, ℡ 01865 (6)13483 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
psycopg2 and "idle in transaction" messages
Hi all, As of last Thursday we've been seeing ~100% CPU usage from Apache, which we believe was caused by Debian Bug #528529[0], whereby psycopg2 was attempting to double free pointers, resulting in segfaults. This was then (we think) leaving database connections open, resulting in postgres saying "no more connections, TYVM" and the whole site 500ing. Not good. On Monday we worked out what was happening and pulled psycopg2 2.0.12 from PyPI, as the bugfix hasn't been backported to Debian Lenny. Everything seemed happy, but now we're seeing similar symptoms again and were wondering if anyone else could help. Versionwise, we have: * Django 1.1 * Python 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2] * Debian Lenny * psycopg2 2.0.12-py2.5-linux-i686 * postgresql 8.3.8 Here're the outputs of a few things that might be useful: * SELECT * FROM pg_stat_activity: http://dpaste.com/131597/ * SELECT * FROM pg_locks: http://dpaste.com/131598/ * The top of 'top': http://dpaste.com/131599/ * A bit of 'ps -Af': http://dpaste.com/131600/ * A screenshot of our CPU usage: http://users.ox.ac.uk/~kebl2765/cpu.png * A screenshot of our load avg: http://users.ox.ac.uk/~kebl2765/load.png The short drops in CPU utilisation were due to apache/postgres/system restarts, and periods of high system CPU usage were generally when it was 500ing. The first time round we had tracebacks and memory dumps in our /var/log/apache2/error.log; now there's nothing useful. Any help would be greatly appreciated! Warm regards, Alex [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528529 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: return a dynamically generated image to the user?
Hi Mark On 10/12/09 16:45, Mark Freeman wrote: > I have recently created a python module which parses an input string > and invokes the program lilypond to generate a music score image. All > of this works fine as a standalone python app. I'm now looking to add > this to my django site so users can enter the text on a form, hit > submit, and have the site return the image of the music score. > > The form submission part is no problem, but I am not sure where to > start with having the view return the image to the page. Anyone have > suggestions for where to start? > We're doing something similar with generating maps. We have a model to represent the generated map to record a hash of its creation parameters (e.g. dimensions, points plotted) and when it was generated. The map is then saved to a cache directory with the hash as a filename. We then have a simple view to serve the page: def generated_map(request, hash): map = get_object_or_404(Map, hash=hash) f = open(map.get_filename(), 'r') return HttpResponse(f, mimetype="image/png") The alternative would be to stick an Alias in your apache conf (assuming you're using apache) to serve the files directly from the filesystem. This solution wouldn't let you perform any authorisation, though. We remove out old maps when we reach some large number in the cache directory so as not to fill up the disk. HTH, Alex PS. Sorry Mark for sending this again; my reply-list button seems to actually be a reply-to-sender button. Silly TB3.04b. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: unicode encoding problem
Hi Bill, Simon, On 04/01/10 16:05, Bill Freeman wrote: > I find the error slightly confusing because the mentioned character, > \xc2, which is capital A with circumflex, doesn't occur in the quoted > part of the text. \xc2 is the first byte of a character encoded in UTF-8 as two bytes. The character you were expecting is U+00C2, being a Unicode codepoint (as opposed to an encoding thereof). For what it's worth, my experience of the method given in the PEP has been positive. Regards, Alex PS. Sorry for the multiple copies, Bill. The Reply-list button in TB3 is (still) broken -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Only Email + Password ( without username )
On 14/01/10 09:51, nameless wrote: > I am asking whether is a good solution to having 2 fields with the > same value ( username and email ) because both are required. > Or is there another solution ? > This depends on whether you don't want distinct usernames hanging around, or you simply want people to be able to log in using their e-mail address. My inclination in the latter case would be to automatically generate usernames as random strings, but not expose them. You can then create a custom authentication backend[0] which uses the email address in place of the username. Usernames are good things to have around to refer to people, as e-mail addresses can change and usernames generally don't. If user details are to be exposed in some way (e.g. by activity feeds or to other users) you want some sort of immutable identifier for each user. Again, the approach you take depends on what you're trying to do and who your audience is. Alex [0] http://docs.djangoproject.com/en/dev/ref/authbackends/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Simple filter query throwing up an error
Hi Darthmahon,
You probably want "from datetime import datetime" at the top, as now()
is buried a bit deeper into the module tree than you'd expected.
That said, isn't your query going to return everything that's happening
at the very instant the query is run? You probably want something like:
from datetime impot date
today = date.today()
Event.objects.filter(date__year = today.year, date__month =
today.month, date__day = today.day)
Hope this helps,
Alex
Darthmahon wrote:
> Hey,
>
> I want to get a list of events that are happening today and I'm using
> this query:
>
> Event.objects.filter(date__exact=datetime.now())
>
> Simple enough, but it throws up this error:
>
> AttributeError at /events/today/
> 'module' object has no attribute 'now'
>
> My model looks like this:
>
> title = models.CharField(maxlength=200)
> slug = models.SlugField(prepopulate_from=('title',))
> body = models.TextField()
> created = models.DateTimeField(auto_now_add=True)
> date = models.DateField()
> time = models.TimeField()
>
> Any ideas? I'm importing datetime at the top of my views.py file
> (where the query is run).
>
> Cheers,
> Chris
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
