Re: Deploying a django application to apach2 on Ubuntu

[David P. Novakovic]

Hey, this post is definitely for the django-users mailing list. This mailing
list is solely for the discussion of django development itself. That is,
discussion about development of the core libraries.

Cheers,

David

On Sat, Jan 29, 2011 at 6:46 PM, Maxim Mai  wrote:

> Hi all,
>
> I am really new to django and apache.
> I've  just finished a django application recently, and now I am have
> problems of deploying it to a server.
>
> system environments:
> ubuntu 10.10
> apache2
> django1.2
> php5
> mod_wsgi
> python2.6
>
> problems are:
>
> 1. I think my apache2 configures are all messed up.
> what happened is I wanted to enable the static files(*.css and image
> files that I need for my templates) serving for my application, then I
> googled online, turns out, there are many versions of HOWTO. So, I
> edited httpd.conf, apache2.conf, sites-available/default, and sites-
> enabled/default... tried a2ensite, a2dissite.
> I've also tried sudo apt-get purge apache2, then reinstalled it. I was
> hoping that I could get a new set of configuration for the apache2.
> that's how i ended up with nothing working, not even phpmyadmin.
>
> 2. how do you serve static media files in development mode?
> I mean, how do you serve those files just using the built-in web
> server? (python manage.py runserver)
>
> 3. are there any good web server software for django applications? or
> are there any good web app hosting for django, google app engine,
> webfaction?
> pros and cons? My application is just a extended version of the built-
> in django admin system: a invoice. book keeping application that
> allows a store owner to manage their daily business with clients,
> invoices, products and shippings.
>
> Thanks,
>
> Maxim Mai
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Query String missing in a GET request

[David P. Novakovic]

Hello,

This is a mailing list to discuss the development of the django
framework itself.

Please post your question to django-users :)

If you find there is an actual bug at play, you may be redirected here..

Cheers,

David

On Tue, Nov 23, 2010 at 3:54 AM, guilhelm  wrote:
> Hi,
>
> I try to create an autocomplete box. The source comes from an ajax
> request to the django server.
> Handling of the request looks like this:
>
> def handler(request):
>  term = request.GET.get('term','')
>  # create json data and send it
>
> Problem is that GET is empty whereas the called url contains "?
> term=...". META['QUERY_STRING'] is empty to.
> If I try to make the request with a post method, it works.
>
> Is there something special to do to make it working ?
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug with testing framework when not using contrib.auth

[David P. Novakovic]

This is certainly an artifact of the fact that messages recent started
supporting anonymous messages. Previously it depended on auth.

I suspect you just need to open a ticket for this.

On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma  wrote:
> I have a large application that doesn't user contrib.auth, and when I
> run `manage.py test` I get a slough of 35 errors, all of which are
> DatabaseError: no such table: auth_user (differing Tracebacks for
> each). I don't have any actual tests yet, just the SimpleTest that
> comes free in tests.py. INSTALLED_APPS is:
>
>    'django.contrib.sessions',
>    'django.contrib.messages',
>    'myproject.myapp',  # Plus 8 more custom apps omitted.
>
>
> With this bug, Django's testing framework is seemingly coupled to a
> contrib app.
>
> One of the Tracebacks:
>
> ==
> ERROR: test_add
> (django.contrib.messages.tests.user_messages.UserMessagesTest)
> --
> Traceback (most recent call last):
>  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
> \messages\tests\user_messages.py", line 13, in setUp
>    self.user = User.objects.create(username='tester')
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \manager.py", line 138, in create
>    return self.get_query_set().create(**kwargs)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \query.py", line 351, in create
>    obj.save(force_insert=True, using=self.db)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \base.py", line 452, in save
>    self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \base.py", line 545, in save_base
>    result = manager._insert(values, return_id=update_pk, using=using)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \manager.py", line 195, in _insert
>    return insert_query(self.model, values, **kwargs)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \query.py", line 1490, in insert_query
>    return query.get_compiler(using=using).execute_sql(return_id)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> \compiler.py", line 786, in execute_sql
>    cursor = super(SQLInsertCompiler, self).execute_sql(None)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> \compiler.py", line 730, in execute_sql
>    cursor.execute(sql, params)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
> \sqlite3\base.py", line 221, in execute
>    return Database.Cursor.execute(self, query, params)
> DatabaseError: no such table: auth_user
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Start project not working

[David P. Novakovic]

Hello, this mailing list is to discuss the development of django itself.

Please use django-users for questions like yours :)

David

On Fri, Oct 29, 2010 at 4:03 PM, aravind  wrote:
> I installed python2.5 and django official
>
> version and also copied admin.py in
>
> scripts but when i use django admin-py
>
> startproject myproject is not working it
>
> s showing the following message
>
>
>
> Usage: django-admin.py subcommand
>
> [options] [args]
>
> Options:
>  -v VERBOSITY, --verbosity=VERBOSITY
>                        Verbosity level;
>
> 0=minimal output, 1=normal output,
>                        2=all output
>  --settings=SETTINGS   The Python path
>
> to a settings module, e.g.
>
>
> "myproject.settings.main". If this isn't
>
> provided, the
>
>
> DJANGO_SETTINGS_MODULE environment
>
> variable will be
>                        used.
>  --pythonpath=PYTHONPATH
>                        A directory to
>
> add to the Python path, e.g.
>
>
> "/home/djangoprojects/myproject".
>  --traceback           Print traceback
>
> on exception
>  --version             show program's
>
> version number and exit
>  -h, --help            show this help
>
> message and exit
>
> Type 'django-admin.py help '
>
> for help on a specific subcommand.
>
> Available subcommands:
>  cleanup
>  compilemessages
>  createcachetable
>  dbshell
>  diffsettings
>  dumpdata
>  flush
>  inspectdb
>  loaddata
>  makemessages
>  reset
>  runfcgi
>  runserver
>  shell
>  sql
>  sqlall
>  sqlclear
>  sqlcustom
>  sqlflush
>  sqlindexes
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis  wrote:
>
> Since dispatch is going to be defined on the base View class, can't we
> omit it from the urlconf and have the URLresolver do:
>
>  if isinstance(view, type) and issubclass(view, View):
>      view = view.dispatch

Russ mentioned this one can't be decorated.

I personally love the classmethod idea, so that's +1 from me for that.

D

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Contributing more

[David P. Novakovic]

Hey,

I've been working on tickets that don't have tests or patches or both,
to help move them along :)

I've found it a good way to get involved with things that aren't too
contentious.

There are a few documentation bugs as well.

Others will certainly have their own take on it too...

David

On Mon, Oct 4, 2010 at 12:11 PM, Laurent Luce  wrote:
> Hello,
>
> I added the localflavor for Belgium as my first contribution. I would
> like to contribute more code wise. I looked at the tickets with
> milestone 1.3 and with no patch. It is hard to know what is critical
> and where help is the most needed.
>
> Can someone tell me what tickets require immediate help and are not
> too complicated for a new contributor. I don't mind spending 2-3 days
> before Oct 18th. I have been using Django for 2 years and I am quite
> familiar with the basics like views, models, templates and forms.
>
> Please let me know.
>
> Laurent
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

Sorry, I keep top replying in my emails. It's because I'm mostly
taking everything in and not really replying to anyone specifically.

I _really_ like the idea of View being synonymous with a ResponseFactory.

Using __call__:
The view base class can take *args and  **kwargs and apply them lazily
when __call__ is called. This is basically like the copy+call one,
except there is no copy,

class ResponseFactory:   #might as well be called View
def __init__(self,*args,**kwargs): # discourage args/kwargs
self.args = args
self.kwargs = kwargs

def __call__(self,*args,**kwargs):
response = self.__class__(*self.args,
**self.kwargs).dispatch(*args, **kwargs)
return response


No copy. An explicit contract, with an understood pattern (Factory)
that the initial args and kwargs will be applied to every instance
created from this one (and thus should be considered volatile).

Even though its trivially different, it feels a lot cleaner in my head :)

D

On Sun, Oct 3, 2010 at 12:44 PM, Russell Keith-Magee
 wrote:
> 2010/10/3 Łukasz Rekucki :
>> On 2 October 2010 12:32, Russell Keith-Magee  wrote:
>>> 2010/10/2 Łukasz Rekucki :
 On 2 October 2010 10:34, Russell Keith-Magee  
 wrote:
>> To sum this up, I think the important questions are:
>>
>>   1) Do View instances need to share anything ? I say: yes.
>
> Agreed.
>
>>   2) What is the purpose of this shared objects ?
>>      I say: customization of *default* view settings (like default
>> redirect path, default template, default page size in pagination).
>
> Shared settings from the constructor -- agreed. Instance variables
> that form part of view logic are another (albiet related) issue.
>
>>   3) How do we make this shared settings immutable between requests
>> (this has nothing to do with thread-safety) ?
>
> It's entirely about thread safety; if you've got code modifying any
> instance variable, and those instance variables don't have isolated
> state between class instances, thread safety will be the first
> manifestation.
>
>>      This is largely the topic of this thread. Deep copying it
>> everytime is surely the most secure option, but not very efficient.
>
> There are also some objects that aren't deep-copyable.
>
>> Another way is to keep this settings as class attributes and assume
>> the user is sane enough not to share mutable object between class
>> instances.
>
> ... and that's a *really* big assumption, and one that has potential
> to bite users on the butt really easily -- especially new developers.
>
 def with_args(view_cls, **kwargs):
    return type(view_cls.__name__, (view_cls,), kwargs)

 # in urls.py:

  (r'^somepath', with_args(MyView, option=False)),
  # or even
  (r'^somepath', MyView.with(option=False)),
>>>
>>> I can't deny this would work. It just doesn't feel very Pythonic to me.
>>
>> I don't share your feeling about this. Django already uses a similar
>> idiom in ModelForms - you pass in a base form, some extra options and
>> get a new subclass. Also, I would consider this as a shortcut for
>> advanced users and advice beginners to use subclassing.
>
> I'm not sure I see the comparison. ModelForms are declared using a
> metaclass; instances are defined in the normal way that every class is
> defined. There is a modelform_factory() et al, but they're not class
> methods; they're standalone functions that can be used to construct
> new classes.
>
> MyView.with(xxx) -- a class method that is a class factory -- isn't a
> construct with precedent in Django's codebase AFAICT.
>
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

On Sat, Oct 2, 2010 at 12:26 PM, Ian Lewis  wrote:
> On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor  wrote:
>> Not really.  The big win from a class-based view is not being able to
>> store state, you can do that with local variables, it's being able to
>> override parts of the behavior without needing to rewrite the entire
>> view, or add 101 parameters.
>
> Agreed. There is already an object to store state per request. It's
> the request object. It's there for a reason. Adding data to the
> class instance would be like adding data to the view function (like
> view_function.data = "spam"). No one would agree that's a good idea.
>

By this reasoning, when you add extra helper methods to your class,
which is the reason for OO views, you need to add/use the data those
methods will modify to the request object? That just doesn't make
sense to me at all. It reminds me of the "Feature Envy" code smell..

D

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

Yeah, I actually read your modification of the trac page after posting this :\

I guess what I'm getting at is the more general issue of maintaining
the same interface... is it really that important?

If people acknowledge that they are using a different system, then
they can adjust their expectations accordingly.

For example, this specific case of a decorator could be changed
slightly so that the decorator is passed as a parameter to the url
conf, or something like that.

If the goal here is to be completely unsurprising and fit something
into the existing system then I'll let the thread get back on topic :)
I was just considering the possibility of actually providing another
option which is a bit more of a radical change, but also doesn't
involve some quicky ... tweaks..

On Sat, Oct 2, 2010 at 11:14 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Saturday, October 2, 2010, David P. Novakovic
> <davidnovako...@gmail.com> wrote:
>> My problem with all of this is that it feels like a hell of a lot of
>> hoopjumping to deal with something that could be solved in the
>> Resolver.
>>
>> I may be missing something obvious here, so please tell me if I am..
>> but couldn't the resolver just check that quacks like something
>> OOViewish has been passed in and simply branch and init the class
>> before calling the view in the same way it normally would?
>>
>> pseudo code follows:
>>
>> obj = None
>> func = None
>> if hasattr(view,something_an_ooview_has): #general ooview instance checking
>>     obj = view()
>>     func = view.dispatch
>> else:
>>     func = view
>>
>> response = func(...)
>> return response
>>
>
> Sure. Now decorate the view.
>
> Decorating views in the urlconf is a very common and useful pattern,
> but it's a pattern that is pretty much impossible using the approach
> you describe.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

Sorry in my previous email you could simply pass the uninstantiated
class in the url pattern.

url(r'...',MyOOView,...)

On Sat, Oct 2, 2010 at 8:57 AM, David P. Novakovic
<davidnovako...@gmail.com> wrote:
> My problem with all of this is that it feels like a hell of a lot of
> hoopjumping to deal with something that could be solved in the
> Resolver.
>
> I may be missing something obvious here, so please tell me if I am..
> but couldn't the resolver just check that quacks like something
> OOViewish has been passed in and simply branch and init the class
> before calling the view in the same way it normally would?
>
> pseudo code follows:
>
> obj = None
> func = None
> if hasattr(view,something_an_ooview_has): #general ooview instance checking
>    obj = view()
>    func = view.dispatch
> else:
>    func = view
>
> response = func(...)
> return response
>
>
> D
>
> On Sat, Oct 2, 2010 at 4:14 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>>
>> On Oct 1, 4:16 pm, Russell Keith-Magee <russ...@keith-magee.com>
>> wrote:
>>
>>> "Don't use instance variables on a class" isn't advice you're going to
>>> see printed very often. Yet that would be the advice that would be
>>> *required* in order to use stateless class-based views in the way you
>>> describe.
>>>
>>> Objects have state. I don't think it's at all unreasonable to suggest
>>> that a instances of a class based view should be able to have state.
>>> And even if we documented the fact that they can't have state, I'm
>>> willing to *guarantee* that people will *try* to make them stateful.
>>>
>>
>> To perhaps complicate the issue a little further, I think there's a
>> distinction between read-only state and mutable state. It seems
>> reasonable to let view class instances have read-only state (this
>> might be part and parcel of increased [re]usability) such as template
>> names, output mimetype configuration etc. This would be quite safe,
>> ISTM.
>>
>> For mutable state during request processing, I'd vote for sticking it
>> all in the request. Then your method signatures need only include the
>> request - not unreasonable - and if for some reason you couldn't do
>> that, there's always thread locals for the requests (duck ;-))
>>
>> Regards,
>>
>> Vinay Sajip
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #6735 -- Class based generic views: call for comment

[David P. Novakovic]

My problem with all of this is that it feels like a hell of a lot of
hoopjumping to deal with something that could be solved in the
Resolver.

I may be missing something obvious here, so please tell me if I am..
but couldn't the resolver just check that quacks like something
OOViewish has been passed in and simply branch and init the class
before calling the view in the same way it normally would?

pseudo code follows:

obj = None
func = None
if hasattr(view,something_an_ooview_has): #general ooview instance checking
obj = view()
func = view.dispatch
else:
func = view

response = func(...)
return response


D

On Sat, Oct 2, 2010 at 4:14 AM, Vinay Sajip  wrote:
>
> On Oct 1, 4:16 pm, Russell Keith-Magee 
> wrote:
>
>> "Don't use instance variables on a class" isn't advice you're going to
>> see printed very often. Yet that would be the advice that would be
>> *required* in order to use stateless class-based views in the way you
>> describe.
>>
>> Objects have state. I don't think it's at all unreasonable to suggest
>> that a instances of a class based view should be able to have state.
>> And even if we documented the fact that they can't have state, I'm
>> willing to *guarantee* that people will *try* to make them stateful.
>>
>
> To perhaps complicate the issue a little further, I think there's a
> distinction between read-only state and mutable state. It seems
> reasonable to let view class instances have read-only state (this
> might be part and parcel of increased [re]usability) such as template
> names, output mimetype configuration etc. This would be quite safe,
> ISTM.
>
> For mutable state during request processing, I'd vote for sticking it
> all in the request. Then your method signatures need only include the
> request - not unreasonable - and if for some reason you couldn't do
> that, there's always thread locals for the requests (duck ;-))
>
> Regards,
>
> Vinay Sajip
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: four NoSQL backends you want? :)

[David P. Novakovic]

This has probably been discussed at great length previously... but my
2c follows:

If you are using a column/doc store you are trying to solve a
different problem than if you are using an SQL db.

How important is 100% interop? Surely it's about documenting the
differences between them and providing an interface to document stores
that isn't completely foreign to people who know how to use the django
ORM?

In which case it seems that the trust issue Russ was talking about
earlier is the main barrier here. We need more trusted people to be
using the non-rel code.

Surely that doesn't mean the project should end. Maybe there is an
interim measure that can be taken, like the django project can
recommend that people use non-rel when they want column store support
in their app with the disclaimer that it is not officially supported.
>From there it could become the defacto standard, and following that it
may be accepted?

Just throwing alternative ideas out here.

D

On Tue, Sep 28, 2010 at 9:22 AM, Russell Keith-Magee
 wrote:
> On Tue, Sep 28, 2010 at 1:51 AM, Mark Bucciarelli  wrote:
>> On Sat, Sep 25, 2010 at 10:21:06PM +0800, Russell Keith-Magee wrote:
>>>
>>> The number 4 wasn't actually the important bit - it was that I want
>>> to see a range of noSQL approaches represented. I don't want to see
>>> 4 key-value stores; I want to see a key-value store, and a document
>>> store, and a column store, etc. I need to see that the API is rich
>>> enough to cover all noSQL bases.
>>>
>>
>> I've seen references to Django's test suite on this list in the past,
>> and I'm curious why the criteria can't simple be: "a clean run on our
>> test suite."
>>
>> I have a backend [1] for MonetDB (a column store DB).  They expose a SQL
>> wrapper around their non-SQL engine, which makes it pretty easy to
>> support.
>>
>> On my todo list was to see how it fares with the Django test-suite.
>> I guess the test suite must not cover all the basees, making it a
>> necessary but not sufficient criteria for inclusion?
>>
>> Correct?
>
> Well, sort of.
>
> The problem is that NoSQL stores don't necessarily have feature parity
> with relational databases. For example, the concept of a join is
> pretty fuzzy when it comes to stores like MongoDB and GAE. You *could*
> emulate join with a series of lookups, but that could get pretty
> spectacularly inefficient, so we're not going to force stores to
> emulate behaviors that aren't extensions of their native capabilities.
> Given that there isn't feature parity, Django's test suite won't be
> able to pass completely.
>
> We're in the process of migrating Django's test suite to use
> unittest2, which, in turn, means we have access to the @skipif and
> @skipunless decorators; we're going to be annotating a bunch of tests
> to make them 'feature aware' (e.g., don't run this test if the backend
> doesn't support transactions). A logical extension of this is to add
> other feature checks like "backend supports joins", and annotate the
> test suite appropriately. This would allow the noSQL backend to pass
> the suite, albeit with a lot of test skips.
>
> My (mild) concern with this approach is that a feature that this will
> make it too easy to get a suite 'passing', and we'll miss some detail
> in the process. For example, if we make it easy to skip the aggregates
> tests, and a backend actually does support aggregates, then it becomes
> easy to say "Oh, we *could* do aggregates, but we just haven't yet".
> Now, this may be entirely true, but it could also be the case that
> Django's backend API is structured in such as way that aggregates are
> impossible to implement.  Making it easy to skip tests masks the
> complications that may exist in the API.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Meta.required_together

[David P. Novakovic]

Is it? I read this as different to anything in the ORM.

This is about conditionally requiring a second field if one is filled
out. Normally it would be done at the JS level.

I think it's a good idea, assuming I haven't missed something that
already does this.

I can't help thinking this is part of a much larger problem though.
That problem is multifield validation. I think we'd have to address
that issue first before working on this specific case that is probably
the simplest.

Maybe this has been considered before, but was dropped because the
idea is too hard to encapsulate in a simple Meta style option?

David

On Mon, Sep 27, 2010 at 5:18 PM, Florian Apolloner
 wrote:
> Please post usage questions to the users list. This is already doable
> with model validation.
>
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #12012 Logging: request for comments

[David P. Novakovic]

Hey mate,

Great stuff! A cursory glance shows there isn't anything to log debug
output from url resolution.. something I think I need to add.. I'll
busy a ticket for it :)

D

On Sat, Sep 25, 2010 at 4:16 PM, Russell Keith-Magee
 wrote:
> Hi all,
>
> I've just uploaded a first draft at a patch introducing logging into
> Django [1]. I'm calling for feedback on this patch.
>
> [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff
>
> This patch is heavily drawn from the work that Vinay Sajip has done in
> this area, but it also includes some significant changes to his most
> recent patches.
>
> The patch introduces two settings:
>
> LOGGING_CONFIG - a callable that should be used to configure the
> logging machinery
> LOGGING - the configuration data to pass to the configuration function.
>
> By default, LOGGING_CONFIG points to logging.config.dictConfig, which
> means that LOGGING should be a dict-style logging configuration (as
> introduce by Python 2.7). A copy of dictConfig is included in utils
> for backwards compatibility. However, by changing LOGGING_CONFIG, you
> could use any configuration scheme you like.
>
> In addition, a new convention is introduced. If a Django app includes
> a 'startup.py' as a sibling module to models.py, tests.py etc, then
> this module will be loaded *exactly once* during the startup of the
> app. It will be loaded *after* the settings have been initialized, but
> *before* models.py has been imported.
>
> The patch includes the changes to the new project settings.py to show
> what LOGGING would look like in practice. This logging configuration
> puts everything to console, except for errors in the request process,
> which are mailed to the admin. This means redirecting 500 errors to
> something other than your email box is now a 1 line configuration
> item.
>
> The patch also includes logging entries for everywhere in the code
> where a 4XX or 5XX error is raised. 4XX's are raised as warnings;
> 5XX's as errors.
>
> Lastly, there is a separate logger that logs, at the debug level,
> every SQL statement that is executed. If you add a handler for
> django.db.backends that catches the DEBUG level, you will get this
> output.
>
> There are no docs because I'm waiting for the design to be finalized
> before I start writing; there are no tests because this is something
> that is a little difficult to test.
>
> At this point, I'm calling for feedback, particularly on the following:
>
>  * logging config as the last stage of settings loading. Is this the
> right place? Can anyone think of a better place?
>
>  * The default logging configuration. Have I got the
> propagate/override options right for sensible defaults (both in global
> and new-project settings)?
>
>  * The logging calls that have been introduced. Is this too much or
> too little? I'd rather err on the side of caution here (we can always
> add extra logging later), but I'd like suggestions on anything else
> people think should be logged. Also, are they logged at the right
> level (e.g., is a 404 a warning?).
>
>  * The startup.py convention (and implementation). Is this necessary?
> Does it address (or not address) any other prominent "on startup" use
> cases? There's also a crossover here with Arthur's GSoC work; is the
> startup code sufficiently important that we need it anyway, or can we
> defer until the app refactor lands?
>
> So - have at it. I'm really excited by this; so let me know everywhere
> I've messed up so that we can get this into trunk.
>
> Russ %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Something.is_live instead of implementation specific is_live settings

[David P. Novakovic]

This link and the comments suggest some good stuff... particularly the
comment from Malcolm and the original post.

http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-production-why-the-hoops/


On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
<davidnovako...@gmail.com> wrote:
> The thing is, in production mode you normally have to define where
> your settings are anyway, so you pass the unusual settings file name
> there, and just use the regular settings.py for your development.
>
> So then you are passing the settings configuration information once in
> the production server's configuration, not every time you run your
> development server.
>
> I think people with any decent sized project have addressed this issue
> in their own way that suits their own needs.
>
> For example we have lots of settings files and just import the
> relevant settings into a final file.
>
> For testing I do what i mentioned in my previous email.
>
> Like anything on here, you need to ask whether what you are suggesting
> would actually be better off as part of the core or if it works just
> fine as something that people can choose to use themselves...
>
> I think most people use whatever system they are happy with and it
> doesn't get in the way of deployment/development. Thus this fails to
> meet one of the critical requirements for consideration for inclusion
> into core.
>
> D
>
> On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> Thanks David, but I'm talking about having something built in. For
>> instance, passing a variable to the "Development" server to tell it
>> you're in "Development" seems a bit redundant, no?
>>
>> On Sep 23, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com>
>> wrote:
>>> As for running different configs:
>>>
>>> manage.py runserver --settings=settings_test
>>>
>>> etc..
>>>
>>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 
>>> wrote:
>>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <baxterstock...@gmail.com> 
>>> > wrote:
>>> >> I'm simply proposing the idea of having the development server
>>> >> explicitly set something to indicate a "in development" status, so
>>> >> that if that does not exist you can make the assumption that the
>>> >> project is live.
>>>
>>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it.
>>>
>>> > Jacob
>>>
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "Django developers" group.
>>> > To post to this group, send email to django-develop...@googlegroups.com.
>>> > To unsubscribe from this group, send email to 
>>> > django-developers+unsubscr...@googlegroups.com.
>>> > For more options, visit this group 
>>> > athttp://groups.google.com/group/django-developers?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Something.is_live instead of implementation specific is_live settings

[David P. Novakovic]

The thing is, in production mode you normally have to define where
your settings are anyway, so you pass the unusual settings file name
there, and just use the regular settings.py for your development.

So then you are passing the settings configuration information once in
the production server's configuration, not every time you run your
development server.

I think people with any decent sized project have addressed this issue
in their own way that suits their own needs.

For example we have lots of settings files and just import the
relevant settings into a final file.

For testing I do what i mentioned in my previous email.

Like anything on here, you need to ask whether what you are suggesting
would actually be better off as part of the core or if it works just
fine as something that people can choose to use themselves...

I think most people use whatever system they are happy with and it
doesn't get in the way of deployment/development. Thus this fails to
meet one of the critical requirements for consideration for inclusion
into core.

D

On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> Thanks David, but I'm talking about having something built in. For
> instance, passing a variable to the "Development" server to tell it
> you're in "Development" seems a bit redundant, no?
>
> On Sep 23, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com>
> wrote:
>> As for running different configs:
>>
>> manage.py runserver --settings=settings_test
>>
>> etc..
>>
>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 
>> wrote:
>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> >> I'm simply proposing the idea of having the development server
>> >> explicitly set something to indicate a "in development" status, so
>> >> that if that does not exist you can make the assumption that the
>> >> project is live.
>>
>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it.
>>
>> > Jacob
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[David P. Novakovic]

To take something constructive from this.. perhaps backend could be a
property that raises a more meaningful exception when it is called the
wrong way?

I'm not particularly for or against the idea.. but I know raising more
meaningful exceptions is an issue that has received some attention
previously.

Thoughts anyone?

On Fri, Sep 24, 2010 at 9:32 AM, David P. Novakovic
<davidnovako...@gmail.com> wrote:
> Apart from being slightly offended at you posting a Joel Spolski link
> to make a point, I'll address the actual issue at hand :P
>
> These docs pretty clearly show authenticate happening before login.
> Both in examples and the actual docs.
>
> http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in
>
> Notice in particular:
>
> """
> Calling authenticate() first
>
> When you're manually logging a user in, you must call authenticate()
> before you call login(). authenticate() sets an attribute on the User
> noting which authentication backend successfully authenticated that
> user (see the backends documentation for details), and this
> information is needed later during the login process.
> """
>
> The only time I could see this being a documentation issue is when
> someone is implementing their own authenticate function but this
> breaks the django convention if simply implementing a backend and
> adding it to the list of auth backends and letting authenticate()
> provide the actual authentication.
>
> So yep, unfortunately this is an issue for django-users.
>
> David
>
>
>
> On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> It is a problem with Django. I thought it was a problem with the code
>> but it isn't. It's a problem with the documentation, or worse. An
>> function of an API that requires running of another function to alter
>> an object behind the scenes is an architectural problem that needs
>> fixing. See http://www.joelonsoftware.com/articles/LeakyAbstractions.html
>> - and furthermore, if the choice is made to leave problems like this
>> unfixed, they should be documented as so. The current documentation
>> here says, "It takes an HttpRequest object and a User object.". This
>> isn't true, as as simple User object will not suffice. It should say,
>> "It takes an HttpRequest object and a User object that has been run
>> through the function authenticate() first to alter the auth backends
>> that are attached as attributes to it.".
>>
>> This has very bad code smell, IMHO.
>>
>> On Sep 23, 3:47 pm, "David P. Novakovic" <davidnovako...@gmail.com>
>> wrote:
>>> This probably should have been posted to django-users anyway.
>>>
>>> Chances are, getting a stacktrace like this one or the last error you
>>> posted are actually problems with your code and not django itself.
>>>
>>> Unless you can show that it is actually a problem with django and not
>>> the way you are using it, it'd be better addressed on django-users
>>> first.
>>>
>>> David
>>>
>>> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 
>>> wrote:
>>> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma <baxterstock...@gmail.com> 
>>> > wrote:
>>> >> Hey Jacob, understood. Here's some more details that might help:
>>> > [snip]
>>> >>                if user.check_password(request.POST.get('password',
>>> >> '')):
>>> >>                    login(request, user)
>>>
>>> > As Santiago mentioned, you need to call authenticate() before calling
>>> > login(). 
>>> > Seehttp://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth...
>>> > for details.
>>>
>>> > Jacob
>>>
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "Django developers" group.
>>> > To post to this group, send email to django-develop...@googlegroups.com.
>>> > To unsubscribe from this group, send email to 
>>> > django-developers+unsubscr...@googlegroups.com.
>>> > For more options, visit this group 
>>> > athttp://groups.google.com/group/django-developers?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[David P. Novakovic]

Apart from being slightly offended at you posting a Joel Spolski link
to make a point, I'll address the actual issue at hand :P

These docs pretty clearly show authenticate happening before login.
Both in examples and the actual docs.

http://docs.djangoproject.com/en/dev/topics/auth/#how-to-log-a-user-in

Notice in particular:

"""
Calling authenticate() first

When you're manually logging a user in, you must call authenticate()
before you call login(). authenticate() sets an attribute on the User
noting which authentication backend successfully authenticated that
user (see the backends documentation for details), and this
information is needed later during the login process.
"""

The only time I could see this being a documentation issue is when
someone is implementing their own authenticate function but this
breaks the django convention if simply implementing a backend and
adding it to the list of auth backends and letting authenticate()
provide the actual authentication.

So yep, unfortunately this is an issue for django-users.

David



On Fri, Sep 24, 2010 at 9:02 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> It is a problem with Django. I thought it was a problem with the code
> but it isn't. It's a problem with the documentation, or worse. An
> function of an API that requires running of another function to alter
> an object behind the scenes is an architectural problem that needs
> fixing. See http://www.joelonsoftware.com/articles/LeakyAbstractions.html
> - and furthermore, if the choice is made to leave problems like this
> unfixed, they should be documented as so. The current documentation
> here says, "It takes an HttpRequest object and a User object.". This
> isn't true, as as simple User object will not suffice. It should say,
> "It takes an HttpRequest object and a User object that has been run
> through the function authenticate() first to alter the auth backends
> that are attached as attributes to it.".
>
> This has very bad code smell, IMHO.
>
> On Sep 23, 3:47 pm, "David P. Novakovic" <davidnovako...@gmail.com>
> wrote:
>> This probably should have been posted to django-users anyway.
>>
>> Chances are, getting a stacktrace like this one or the last error you
>> posted are actually problems with your code and not django itself.
>>
>> Unless you can show that it is actually a problem with django and not
>> the way you are using it, it'd be better addressed on django-users
>> first.
>>
>> David
>>
>> On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 
>> wrote:
>> > On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> >> Hey Jacob, understood. Here's some more details that might help:
>> > [snip]
>> >>                if user.check_password(request.POST.get('password',
>> >> '')):
>> >>                    login(request, user)
>>
>> > As Santiago mentioned, you need to call authenticate() before calling
>> > login(). 
>> > Seehttp://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth...
>> > for details.
>>
>> > Jacob
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 'User' object has no attribute 'backend' - issue with using auth.login()

[David P. Novakovic]

This probably should have been posted to django-users anyway.

Chances are, getting a stacktrace like this one or the last error you
posted are actually problems with your code and not django itself.

Unless you can show that it is actually a problem with django and not
the way you are using it, it'd be better addressed on django-users
first.

David

On Fri, Sep 24, 2010 at 5:41 AM, Jacob Kaplan-Moss  wrote:
> On Thu, Sep 23, 2010 at 2:18 PM, Yo-Yo Ma  wrote:
>> Hey Jacob, understood. Here's some more details that might help:
> [snip]
>>                if user.check_password(request.POST.get('password',
>> '')):
>>                    login(request, user)
>
> As Santiago mentioned, you need to call authenticate() before calling
> login(). See 
> http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.login
> for details.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Something.is_live instead of implementation specific is_live settings

[David P. Novakovic]

As for running different configs:

manage.py runserver --settings=settings_test

etc..

On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss  wrote:
> On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma  wrote:
>> I'm simply proposing the idea of having the development server
>> explicitly set something to indicate a "in development" status, so
>> that if that does not exist you can make the assumption that the
>> project is live.
>
> This is exactly what the settings.DEBUG flag is for. Use it. Love it.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Inclusion of easy-thumbnails into Django Contrib

[David P. Novakovic]

Actually, that really did sound negative. Sorry :)

Is there a trac ticket open to address this issue? Generally it'd be
better to get discussion happening over a ticket and if there are
serious issues that need to be addressed then they can be discussed
here.

I know it'd be nice to get things like easy-thumbnails accepted into
django.contrib , but the truth is that this probably falls outside of
things that that should be in contrib. Contrib isn't really an easier
way to get stuff into django, it still has to satisfy a bunch of
conditions like the rest of the code in the core.

The real question is not "can it be included?" but why is it a problem
that this is a third party lib at the moment? Is there a strong case
that it be better if it was part of django core or does it do its job
just fine the way it is now?

David


On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
<davidnovako...@gmail.com> wrote:
> I don't want to sound negative, but answering your own question before
> anyone else can doesn't change the answer ;)
>
> D
>
> On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> Is there any plans to incorporate 
>> http://github.com/SmileyChris/easy-thumbnails/
>> into django.contrib? I have seen so many apps/libraries come into and
>> go out of existence (http://code.djangoproject.com/wiki/ThumbNails for
>> instance mentions sorl-thumbnails which is no longer being developed).
>> I just turned the key with easy-thumbnails and voila. It's like magic,
>> but not. It's easy enough to see what's going on behind the scenes.
>>
>> This is something that, with the help of the core and other
>> contributors, could be really great. It works for me as it it is, but
>> it may not work for a more "enterprise" application that uses S3, etc.
>> It might not be highly efficient (I wouldn't know). It might have bugs
>> that I just haven't noticed yet. I'm mentioning all of this because I
>> know somebody will say, "Why move it into Django if it's doing just
>> fine as a separate project?". After experiencing the bliss I thought
>> I'd drop a line here about it, and see what you guys thought.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Inclusion of easy-thumbnails into Django Contrib

[David P. Novakovic]

I don't want to sound negative, but answering your own question before
anyone else can doesn't change the answer ;)

D

On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma  wrote:
> Is there any plans to incorporate 
> http://github.com/SmileyChris/easy-thumbnails/
> into django.contrib? I have seen so many apps/libraries come into and
> go out of existence (http://code.djangoproject.com/wiki/ThumbNails for
> instance mentions sorl-thumbnails which is no longer being developed).
> I just turned the key with easy-thumbnails and voila. It's like magic,
> but not. It's easy enough to see what's going on behind the scenes.
>
> This is something that, with the help of the core and other
> contributors, could be really great. It works for me as it it is, but
> it may not work for a more "enterprise" application that uses S3, etc.
> It might not be highly efficient (I wouldn't know). It might have bugs
> that I just haven't noticed yet. I'm mentioning all of this because I
> know somebody will say, "Why move it into Django if it's doing just
> fine as a separate project?". After experiencing the bliss I thought
> I'd drop a line here about it, and see what you guys thought.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Error email flooding on high traffic production sites

[David P. Novakovic]

Hey dude,

What about something like sentry or lumberjack?

I haven't looked at them too seriously, but I'd imagine there'd be a
way to do smarter summarizing of emails etc..?

D

On Thu, Sep 9, 2010 at 1:26 PM, Simon Litchfield  wrote:
> Hi all
>
> Default behaviour of sending an email on 500 error is great.
>
> Problem is on high traffic sites, and you might just be making a quick
> update- literally within seconds you can bring your mail server down-
> crash your mail client- or render your gmail account useless.
>
> With "batteries included" and "production ready" ethos in mind, I
> reckon this needs fixing.
>
> 1) Max emails per minute setting
>
> 2) Include alternative error handler middleware in core
>
> I haven't tried it yet, but this looks interesting (note web2py
> includes this) --
> http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home
>
> Thoughts? I know I'm not the only one who has run into this (Russ?)
>
> Cheers
> Simon
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request - set variables in template

[David P. Novakovic]

My 2c: The ability for a template editor (ie a frontend developer) to
set variables in the global namespace opens up the potential for a
designer to clobber variables delivered to the template from the view.
The example you've provided is something that really falls to the
responsibility of the view to decide what is "the one"

On the other hand this would let frontend guys edit the template in
subtle ways without touching the view. The power to make significant
changes to the logic of the template is generally considered off
limits in django land.

Anyway, someone else my pipe up to correct me here :)

On Fri, Aug 27, 2010 at 10:21 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> You absolutely cannot. The "with" statement puts the variable in the
> scope of the "with" statement only, not to mention that would not be
> very explicit at all.
>
> On Aug 26, 6:14 pm, "David P. Novakovic" <davidnovako...@gmail.com>
> wrote:
>> You can basically do this with the "with" 
>> statement:http://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=old...
>>
>> On Fri, Aug 27, 2010 at 10:06 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> > I'm sure this will be met with criticism, but there is a reason why
>> > just about all template languages allow the setting of variables. It
>> > allows you to do things like:
>>
>> > {% for thing in things %}
>> >    {{ thing }}
>> >    {% if thing.is_the_one %}
>> >        {% set_var the_one thing%}
>> >    {% endif %}
>> > {% endfor %}
>>
>> > {{ the_one.name }} is a really good thing. > > href="{{ the_one.get_absolute_url }}">Click here to read more.> > h1>
>>
>> > Instead of having to pass in a variable called "active_one" or
>> > something to that effect from your view. I've provided the
>> > implementation:
>>
>> > class SetVarNode(template.Node):
>> >    def __init__(self, var_name, raw_var_value):
>> >        self.var_name = var_name
>> >        self.variable = template.Variable(raw_var_value)
>>
>> >    def render(self, context):
>> >        context[self.var_name] = self.variable.resolve(context)
>> >        return ''
>>
>> > @register.tag
>> > def set_var(parser, token):
>> >    """
>> >    Example Template:
>>
>> >    {% set_var first_name "Roger" %}
>>
>> >    {{ first_name }}
>>
>> >    Outputs:
>>
>> >    Roger
>> >    """
>> >    try:
>> >        tag_name, var_name, raw_var_value = token.split_contents()
>> >    except ValueError:
>> >        raise template.TemplateSyntaxError(
>> >            '{0} requires 2 arguments.'.format(token.split_contents()
>> > [0])
>> >        )
>> >    return SetVarNode(var_name, raw_var_value)
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to 
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group 
>> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request - set variables in template

[David P. Novakovic]

You can basically do this with the "with" statement:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#with

On Fri, Aug 27, 2010 at 10:06 AM, Yo-Yo Ma  wrote:
> I'm sure this will be met with criticism, but there is a reason why
> just about all template languages allow the setting of variables. It
> allows you to do things like:
>
> {% for thing in things %}
>    {{ thing }}
>    {% if thing.is_the_one %}
>        {% set_var the_one thing%}
>    {% endif %}
> {% endfor %}
>
> {{ the_one.name }} is a really good thing.  href="{{ the_one.get_absolute_url }}">Click here to read more. h1>
>
> Instead of having to pass in a variable called "active_one" or
> something to that effect from your view. I've provided the
> implementation:
>
>
> class SetVarNode(template.Node):
>    def __init__(self, var_name, raw_var_value):
>        self.var_name = var_name
>        self.variable = template.Variable(raw_var_value)
>
>    def render(self, context):
>        context[self.var_name] = self.variable.resolve(context)
>        return ''
>
>
> @register.tag
> def set_var(parser, token):
>    """
>    Example Template:
>
>    {% set_var first_name "Roger" %}
>
>    {{ first_name }}
>
>    Outputs:
>
>    Roger
>    """
>    try:
>        tag_name, var_name, raw_var_value = token.split_contents()
>    except ValueError:
>        raise template.TemplateSyntaxError(
>            '{0} requires 2 arguments.'.format(token.split_contents()
> [0])
>        )
>    return SetVarNode(var_name, raw_var_value)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Patch and tests for #13182

[David P. Novakovic]

http://code.djangoproject.com/ticket/13182

Let me know if there is anything else I can do on this ticket, it is fairly
simple anyway.

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Patch and tests for #12295

[David P. Novakovic]

Mornin'

I've attached a patch with unit tests and updated the existing patch.

Let me know if there is anything else I can do on this one.

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #12074 Fixed patch and added tests.

[David P. Novakovic]

New patch attached : *formset-as_p-as_ul-with-unittests.patch*
*
*
At the moment it is checking the string literal, something I'm a little
opposed to doing. But since it replicates the doctest and all the html seems
to be html5 friendly, so it shouldn't be too much of an issue.

Cheers

On Thu, Aug 5, 2010 at 9:17 AM, David P. Novakovic <davidnovako...@gmail.com
> wrote:

> Hey Alex,
>
> Thanks for the feedback. I actually had checked this with Russ earlier, but
> didn't have a response yet. I prefer TestCases and would be happy to oblige.
>
> I'll move the cases I'm testing to a TestCase in the same file and add the
> relevant import to regressiontests/forms/tests.py
>
> D
>
>
> On Thu, Aug 5, 2010 at 8:55 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
>> On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic
>> <davidnovako...@gmail.com> wrote:
>> > Hey, in the interest of easing myself into helping out I've picked an
>> easy
>> > ticket to get done.
>> > http://code.djangoproject.com/ticket/12074
>> > I've fixed the patch and added tests.
>> > Let me know if I've missed something, or done something wrong :)
>> > Cheers,
>> > David
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Django developers" group.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>>
>> Hey David,
>>
>> Thanks for contributing!  The one reccomendation I'd make is to change
>> the doctests into unittests.  I realize a ton of the formsets tests
>> are doctests, however in general we're trying to move away from them
>> for a number of reasons (mostly that they're a pain in the ass to
>> debug).  If you could switch those to be unittests I'll mark it as
>> RFC.
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your
>> right to say it." -- Voltaire
>> "The people's good is the highest law." -- Cicero
>> "Code can always be simpler than you think, but never as simple as you
>> want" -- Me
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #12074 Fixed patch and added tests.

[David P. Novakovic]

Hey Alex,

Thanks for the feedback. I actually had checked this with Russ earlier, but
didn't have a response yet. I prefer TestCases and would be happy to oblige.

I'll move the cases I'm testing to a TestCase in the same file and add the
relevant import to regressiontests/forms/tests.py

D

On Thu, Aug 5, 2010 at 8:55 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic
> <davidnovako...@gmail.com> wrote:
> > Hey, in the interest of easing myself into helping out I've picked an
> easy
> > ticket to get done.
> > http://code.djangoproject.com/ticket/12074
> > I've fixed the patch and added tests.
> > Let me know if I've missed something, or done something wrong :)
> > Cheers,
> > David
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/django-developers?hl=en.
> >
>
> Hey David,
>
> Thanks for contributing!  The one reccomendation I'd make is to change
> the doctests into unittests.  I realize a ton of the formsets tests
> are doctests, however in general we're trying to move away from them
> for a number of reasons (mostly that they're a pain in the ass to
> debug).  If you could switch those to be unittests I'll mark it as
> RFC.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#12074 Fixed patch and added tests.

[David P. Novakovic]

Hey, in the interest of easing myself into helping out I've picked an easy
ticket to get done.

http://code.djangoproject.com/ticket/12074

I've fixed the patch and added tests.

Let me know if I've missed something, or done something wrong :)

Cheers,

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WAP communicating with server-side Python

[David P. Novakovic]

David,

This mailing list is for the development of the django library itself, not
development WITH the library.

Please direct your question to django-users.

David

On Wed, Aug 4, 2010 at 2:51 AM, shi shaozhong wrote:

> Is there an equivalent mailling list for WAP?
> I am in need of a very simple demo website/webpage accessible by
> mobile handset and simply get a few critical data, e.g.
> its id, or/and x, y, z position.
>
> http://www.google.co.uk/search?hl=en=how+to+mobile+website=8=g10==how+to+mobile_rfai=
>
>
> I want to try out moving my Python internet service on to mobile
> phones.  Therefore, the front-end will have to be in WAP.
>
> All I need is an excellent demo WAP page to show me how to get the
> mobile handset's ID, and x, y, z position.
>
> Regards.
>
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Unit Test on urls / views

[David P. Novakovic]

Hi,

This is the mailing list for discussion around developing the actual django
framework, not the use of the framework.

Your request would be better discussed over at django-users
http://groups.google.com/group/django-users .

Cheers,

D

On Wed, Jul 14, 2010 at 2:22 PM, Pradnya  wrote:

> Hello,
>
> I am want to write django 1.1 test case on fedora 12 x86_64.
> To test the url I want to session to be persistent so that the next
> test can use the same context. I can use client.login() method becoz
> in the application login is rewritten.
>
> If I directly use
> kwargs = {'HTTP_X_REQUESTED_WITH':'XMLHttpRequest'}
> response = self.client.post('/login/', {'username': 't...@test.com',
> 'password': 'test01', 'domain':'demo1'}, **kwargs)
> This works fine but I am not able to test the next url. It's trowing
> following error
> WARNING:root:Caught an exception while processing permission:
> {'content': 'MSHTML', 'name': 'GENERATOR', 'group_name': ''}
> ERROR:root:Permission matching query does not exist.
> Traceback (most recent call last):
>  File "/home/sungard/Portals/trunk/django/portal/../portal/auth.py",
> line 143, in authenticate
>perm = Permission.objects.get(codename = codename)
>  File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
> line 120, in get
>return self.get_query_set().get(*args, **kwargs)
>  File "/usr/lib/python2.6/site-packages/django/db/models/query.py",
> line 305, in get
>% self.model._meta.object_name)
> DoesNotExist: Permission matching query does not exist.
>
>
> Please suggest.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.