Re: A policy on calling super()

[Glin]

Sorry, I had problems to get to my google account, but finally I'm here :).

I wrote to the ticket meanwhile, but you probably not in CC, so I paste it 
here, too:

Having this example:
 
class View(object):
def __init__(self):
print "View init"
#super(View, self).__init__()

class SomeMixin(object):
def __init__(self):
print "SomeMixin init"
super(SomeMixin, self).__init__()

class MyView(View, SomeMixin):
def __init__(self):
print "MyVIew init"
super(MyView, self).__init__()

MyView()
 

With the commented line in the View class, the method SomeMixin.__init__ is 
not called, because mro chain is broken, that's the reason why I filled the 
ticket.
 
Practical use - for exemple in current mixins, there are instance 
attributes which are not defined in __init__, which is bad, code is harder 
to read when new attributes pop up on unusual places, every checker like 
pylint displays warning like:
 
W:127,8:ModelFormMixin.form_valid: Attribute 'object' defined outside __init__
 

So in ModelFormMixin, there should be __init__ which defines 'object' 
attribute (self.object = None), which is IMHO more than good practice.
 
Also having attribute 'object' in __init__, we could avoid ugly 
constructions like now (also in views/generic/edit.py):
 
elif hasattr(self, 'object') and self.object is not None:
 

And that's example in Django itself, I bet there could be lot more in 
various cases of other developers views/mixins, which are hurt by broken 
mro chain.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fb4b4508-99bf-4156-bbdd-f9ee4a957bbd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Specifying the field index types

[Alex Burgel]

On Wednesday, October 2, 2013 1:29:10 PM UTC-4, Zev Benjamin wrote:

> What kind of additional configuration?  One advantage of not specifying 
> the type of the db_index_type field is that you could instantiate an object 
> that encapsulates the configuration.
>

That's true. I am partial to opening up Meta for other reasons, but in this 
case, if you were to have an arbitrary config object that is passed to the 
db backend, then you could specify the App Engine indexes.

App Engine itself creates indexes on each field, by default all fields are 
indexed, so this is something that you have to explicitly turn off. There 
are also composite indexes, which index across many fields, these are 
controlled via a separate App Engine-specific file (so its unrelated to 
this discussion). But on top of all that there's an extension to the app 
engine backend called django-dbindexer that allows you to add more indexes, 
like for case-insensitive queries or contains queries. App Engine can't do 
these things out of the box. Currently, you use another special file for 
these indexes, but it would be nice to have this all configured on the 
field.

--Alex
 

>
> On Wednesday, October 2, 2013 1:19:31 PM UTC-4, Alex Burgel wrote:
>>
>> This is something that I'd also be interested in. For the Google App 
>> Engine backend, you have the ability to create indexes that require more 
>> configuration than just on/off. But I don't think a single additional field 
>> would do the trick for my case.
>>
>> Another option would be to open up the Meta class for custom attributes. 
>> There's a thread which discusses this here:
>>
>> https://groups.google.com/forum/#!topic/django-developers/JEDJYB41LGI
>>
>> The config might look something like this:
>>
>> class Article(db.models):
>>   class Meta:
>> custom_indexes = {'field1': 'hash', 'field2': 'btree'}
>>  field1 = db.IntegerField()
>>  field2 = db.CharField() 
>>
>> The tradeoff would be that the index would not be specified in the field 
>> description, but it would be close enough. (Currently for the app engine 
>> backend, you specify these in a separate file that the backend looks for.)
>>
>> On Monday, September 23, 2013 10:36:56 AM UTC-4, Zev Benjamin wrote:
>>>
>>> Hi,
>>>
>>> I'd like to be able to specify what kind of index the database should 
>>> use for a particular field.  I have a proof of concept branch that works 
>>> with PostgreSQL at 
>>> https://github.com/zbenjamin/django/compare/index-types, but I'd like 
>>> to solicit opinions on whether there's a better way of doing it.  The way 
>>> it works in my branch is that you specify the index type by making the 
>>> Field db_index argument a string containing the name of the index type 
>>> you'd like to use.  Specifying db_index=True uses the default index type.
>>>
>>> Example usage:
>>>
>>> class IndexTest(models.Model):
>>> unindexed = models.IntegerField(db_index=False)
>>> default_indexed = models.IntegerField(db_index=True)
>>> btree_indexed = models.IntegerField(db_index="btree")
>>> hash_indexed = models.IntegerField(db_index="hash")
>>>
>>>
>>>
>>> Zev
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b0ba289-45c7-403f-b6bf-0e646fd139ce%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add strutctured settings module to django 1.7?

[Tino de Bruijn]

On Wed, Oct 2, 2013 at 11:16 AM, Tom Evans  wrote:

> Tracking what login keys are assigned to a specific instance of an
>  application is the entire purpose of configuration management. The
> reason we keep code in VCS is so that we can be assured what is
> deployed is coherent and consistent, the same is true for
> configuration, it must be known and verifiable.
>
> The entire basis of my position is that configuration is essential
> code which must be tracked and be verifiable with an audit history of
> changes. If you don't feel that to be the case, you are unlikely to
> see the benefit in your configuration.
>

Ah oké, our requirements differ I see. But I do think there is a slight
difference between configuration (what apps to use, middleware, etc) and
variables that are specific to the environment, although they are both
specified in the settings at the moment. I think this is also what the
12factor approach is.

The second benefit is in consistency. Both approaches take the same
> overall method, one file contains secrets/host specific configuration
> for this server, the second contains generic configuration, and the
> two are combined. With the environment variables way, where is your
> host specific configuration? It could be in .login, in a gunicorn
> launch script, in a shell script - anywhere. How is the configuration
> defined? Are you "setenv foo bar" because this host is Solaris and
> you're running csh, or is this an "export foo=bar". Perhaps they are
> in your supervisord configuration.
>

That is dependent on how the environment is set up. Maybe you tested your
app on a free Heroku instance, but decide it is not worth the money and put
it on a managed server. Or you switch from your own Solaris box to
something that the client owns. In my setup this does not require code
changes.


> Compare to using a python file - you have full power of the python
> interpreter to do whatever you need. Everything is in one language,
> the same language as your code. All configuration will apply
> regardless of how you start the server, whether it is supervisord
> launching a wsgi process or you running runserver. There is no
> requirement for this file to belong to the same repository as the
> code, or even be in a repository.
>

I am confused. Do you like the structure proposed by Vernon in his first
post? Because that is entirely possible and easy to set up, I also use it
(accompanied by env vars). There is one 'but', you do have to set the
DJANGO_SETTINGS_MODULE env var. :)


> There is absolutely nothing that using environment variables as a
> source of configuration gives you that you cannot do using a python
> configuration file and it makes your configuration management messy
> and chaotic.
>

Well, it makes my code deployable anywhere where I can run python and have
the necessary resources, no matter what they are named, without checking in
code that might break somebody else's environment.


> Cheers
>
> Tom
>

Regards,


Tino

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANQFsQDv71StJG4PQ1unACQN1xg8M619wc2dBhtLgyunCDPFcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Specifying the field index types

[Zev Benjamin]

What kind of additional configuration?  One advantage of not specifying the 
type of the db_index_type field is that you could instantiate an object 
that encapsulates the configuration.


Zev


On Wednesday, October 2, 2013 1:19:31 PM UTC-4, Alex Burgel wrote:
>
> This is something that I'd also be interested in. For the Google App 
> Engine backend, you have the ability to create indexes that require more 
> configuration than just on/off. But I don't think a single additional field 
> would do the trick for my case.
>
> Another option would be to open up the Meta class for custom attributes. 
> There's a thread which discusses this here:
>
> https://groups.google.com/forum/#!topic/django-developers/JEDJYB41LGI
>
> The config might look something like this:
>
> class Article(db.models):
>   class Meta:
> custom_indexes = {'field1': 'hash', 'field2': 'btree'}
>  field1 = db.IntegerField()
>  field2 = db.CharField() 
>
> The tradeoff would be that the index would not be specified in the field 
> description, but it would be close enough. (Currently for the app engine 
> backend, you specify these in a separate file that the backend looks for.)
>
> On Monday, September 23, 2013 10:36:56 AM UTC-4, Zev Benjamin wrote:
>>
>> Hi,
>>
>> I'd like to be able to specify what kind of index the database should use 
>> for a particular field.  I have a proof of concept branch that works with 
>> PostgreSQL at https://github.com/zbenjamin/django/compare/index-types, 
>> but I'd like to solicit opinions on whether there's a better way of doing 
>> it.  The way it works in my branch is that you specify the index type by 
>> making the Field db_index argument a string containing the name of the 
>> index type you'd like to use.  Specifying db_index=True uses the default 
>> index type.
>>
>> Example usage:
>>
>> class IndexTest(models.Model):
>> unindexed = models.IntegerField(db_index=False)
>> default_indexed = models.IntegerField(db_index=True)
>> btree_indexed = models.IntegerField(db_index="btree")
>> hash_indexed = models.IntegerField(db_index="hash")
>>
>>
>>
>> Zev
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dfdaaf76-cf9b-477d-9002-1fde2173e0b2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Specifying the field index types

[Alex Burgel]

This is something that I'd also be interested in. For the Google App Engine 
backend, you have the ability to create indexes that require more 
configuration than just on/off. But I don't think a single additional field 
would do the trick for my case.

Another option would be to open up the Meta class for custom attributes. 
There's a thread which discusses this here:

https://groups.google.com/forum/#!topic/django-developers/JEDJYB41LGI

The config might look something like this:

class Article(db.models):
  class Meta:
custom_indexes = {'field1': 'hash', 'field2': 'btree'}
 field1 = db.IntegerField()
 field2 = db.CharField() 

The tradeoff would be that the index would not be specified in the field 
description, but it would be close enough. (Currently for the app engine 
backend, you specify these in a separate file that the backend looks for.)

On Monday, September 23, 2013 10:36:56 AM UTC-4, Zev Benjamin wrote:
>
> Hi,
>
> I'd like to be able to specify what kind of index the database should use 
> for a particular field.  I have a proof of concept branch that works with 
> PostgreSQL at https://github.com/zbenjamin/django/compare/index-types, 
> but I'd like to solicit opinions on whether there's a better way of doing 
> it.  The way it works in my branch is that you specify the index type by 
> making the Field db_index argument a string containing the name of the 
> index type you'd like to use.  Specifying db_index=True uses the default 
> index type.
>
> Example usage:
>
> class IndexTest(models.Model):
> unindexed = models.IntegerField(db_index=False)
> default_indexed = models.IntegerField(db_index=True)
> btree_indexed = models.IntegerField(db_index="btree")
> hash_indexed = models.IntegerField(db_index="hash")
>
>
>
> Zev
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ac38c2ab-566f-4212-8eba-244f3a074851%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Remove contrib redirect's dependency on sites

[Tim Graham]

Hi Simon,

It may be a viable idea, but looking at the code, it's not obvious to me 
how it would be done. Perhaps you could provide some additional details 
about what you had in mind.

Tim

On Monday, September 30, 2013 10:51:58 PM UTC-4, Simon Litchfield wrote:
>
> Contrib redirects is still a handy little app, but it's dependency on 
> contrib.sites is often unnecessary and a little annoying.
>
> Would anyone else be keen to see the dependency removed, gracefully? If so 
> I'll spin up the code.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d9c08c0d-673d-4d6f-89af-f03485c4f1ff%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add strutctured settings module to django 1.7?

[Jonathan Slenders]

There's nothing that prevents anyone to track the configuration of the 
environment in a VCS.
The guideline that it shouldn't be in the repository of the application 
source code is not against that.

Deployment systems should be able to set-up the environment automatically, 
(by generating a settings_local.py, gunicorn configuration or anything 
else.) 
We use our own system [1], but I guess that puppet or chef have 
configuration files that can be tracked in a VCS as well. 

Personally, I'm also not yet entirely convinced that environment variables 
are always the solution, but I'm convinced that machine specific 
configuration files don't belong in the application's repository.

[1] https://python-deploy-framework.readthedocs.org



Le mercredi 2 octobre 2013 11:16:51 UTC+2, Tom Evans a écrit :
>
>
> Tracking what login keys are assigned to a specific instance of an 
> application is the entire purpose of configuration management. The 
> reason we keep code in VCS is so that we can be assured what is 
> deployed is coherent and consistent, the same is true for 
> configuration, it must be known and verifiable. 
>
> The entire basis of my position is that configuration is essential 
> code which must be tracked and be verifiable with an audit history of 
> changes. If you don't feel that to be the case, you are unlikely to 
> see the benefit in your configuration. 
>
> The second benefit is in consistency. Both approaches take the same 
> overall method, one file contains secrets/host specific configuration 
> for this server, the second contains generic configuration, and the 
> two are combined. With the environment variables way, where is your 
> host specific configuration? It could be in .login, in a gunicorn 
> launch script, in a shell script - anywhere. How is the configuration 
> defined? Are you "setenv foo bar" because this host is Solaris and 
> you're running csh, or is this an "export foo=bar". Perhaps they are 
> in your supervisord configuration. 
>
> Compare to using a python file - you have full power of the python 
> interpreter to do whatever you need. Everything is in one language, 
> the same language as your code. All configuration will apply 
> regardless of how you start the server, whether it is supervisord 
> launching a wsgi process or you running runserver. There is no 
> requirement for this file to belong to the same repository as the 
> code, or even be in a repository. 
>
> There is absolutely nothing that using environment variables as a 
> source of configuration gives you that you cannot do using a python 
> configuration file and it makes your configuration management messy 
> and chaotic. 
>
> Cheers 
>
> Tom 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ebfd3e1-d71a-4df0-a003-5d4b01118ab0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add strutctured settings module to django 1.7?

[Tom Evans]

On Tue, Oct 1, 2013 at 6:42 PM, Tino de Bruijn  wrote:
> To all of you who don't see benefit in putting certain (definitely not all!)
> settings in the environment, I would like to say: try it. It will finally
> make sense that you set DJANGO_SETTINGS_MODULE in the first place. I never
> understood why anybody would want that until this :D.
>
> I was sceptical first as well, but tried out Heroku and therefore this
> method. I have since converted all projects to a structure where environment
> specific variables are stored, well, in the environment. Still my settings
> is a module, where prod.py and dev.py inherit from common.py, but that is
> mainly because certain apps are not necessary on either dev of production
> servers. So that is all checked into the repository. I don't see any
> necessity to store those environment vars in a repository, as they contain
> login keys and static files buckets etc.

Tracking what login keys are assigned to a specific instance of an
application is the entire purpose of configuration management. The
reason we keep code in VCS is so that we can be assured what is
deployed is coherent and consistent, the same is true for
configuration, it must be known and verifiable.

The entire basis of my position is that configuration is essential
code which must be tracked and be verifiable with an audit history of
changes. If you don't feel that to be the case, you are unlikely to
see the benefit in your configuration.

The second benefit is in consistency. Both approaches take the same
overall method, one file contains secrets/host specific configuration
for this server, the second contains generic configuration, and the
two are combined. With the environment variables way, where is your
host specific configuration? It could be in .login, in a gunicorn
launch script, in a shell script - anywhere. How is the configuration
defined? Are you "setenv foo bar" because this host is Solaris and
you're running csh, or is this an "export foo=bar". Perhaps they are
in your supervisord configuration.

Compare to using a python file - you have full power of the python
interpreter to do whatever you need. Everything is in one language,
the same language as your code. All configuration will apply
regardless of how you start the server, whether it is supervisord
launching a wsgi process or you running runserver. There is no
requirement for this file to belong to the same repository as the
code, or even be in a repository.

There is absolutely nothing that using environment variables as a
source of configuration gives you that you cannot do using a python
configuration file and it makes your configuration management messy
and chaotic.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1LTavB%2BreZDONOAmq2OZvtsEhcCc5q5ymn3JAisy3iALg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.