Re: Benevolent Dicta^H^H^H Designer for Life

Congratulations Idan! I look forward to see what you have in mind for the admin and forms. -- 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

Re: Benevolent Dicta^H^H^H Designer for Life

Hi folks -- Thanks for the intro, Idan! I thought I'd just fill in a few things from my point of view and give a bit of background to this: It turned out that quite a group of core devs ended up coming to PyCon a couple weeks ago so we ended up having an impromptu lunch and meeting. One of the

Benevolent Dicta^H^H^H Designer for Life

And lo, the core team spake amongst themselves, crying: "Who shall take up the mantle of designer among us? Wilson departed many moons ago for the land of Rdio, and the people cry out for one to provide succour to those who want a more beautiful Django, and yea, a Django that listens to

Re: Composite primary keys

On Mon, Mar 21, 2011 at 2:33 AM, Christophe Pettus wrote: > I'd like to make one more pitch for a slightly different implementation here. >  My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't

Re: secret key from file...

I don't think settings.py needs to be any more complicated by default. Personally, I do keep my db passwords in the settings file under version control. It seems pretty clear that it shouldn't be under *public* revision control. I also do (nearly) exactly what you describe to load the secret key

Re: secret key from file...

On 21 March 2011 18:07, Matt Harasymczuk wrote: > Thats right, > there should be a secret_settings.py file with db credentials and > secret_key > also a warning that it should not be added to version control settings.py already has a warning: # Make this unique, and

Re: secret key from file...

Thats right, there should be a secret_settings.py file with db credentials and secret_key also a warning that it should not be added to version control -- Matt Harasymczuk http://www.matt.harasymczuk.pl On Mar 21, 5:07 pm, Kristaps Kūlis wrote: > "real" config should

Re: Improving Class based views names

On 03/21/2011 09:14 AM, daonb wrote: > On Mar 20, 4:49 am, Carl Meyer wrote: >> Those last five characters in "get_context_data" actually serve quite a >> useful purpose, IMO. They clarify that the return value is just the data >> that will go into building a context (a

Re: secret key from file...

What we use is a settings.cfg, which is an ini file for global configurations. Database settings, etc. We need to share these settings across different languages and parts of our application. You can set up your ini file as such: [secret] key=abcdefghijklmnopqrstuvwxyz0123456789 ini files

Re: secret key from file...

"real" config should not be in version control system, only reference config should be stored in version control. Consider database credentials - they should not be publicly available / downloadable from internet and they fall in same category - sensitive information in settings.py . Memcache

Re: Summer of Code 2011: students wanted!

On Mon, Mar 21, 2011 at 10:51 AM, Raphael Passini Diniz < raphapass...@gmail.com> wrote: > Is needed be an undergrad student to join in the GSoC? > > > 2011/3/21 Andrew Godwin > >> Hello everyone, >> >> Django has once again been accepted as one of the participating projects

Re: Summer of Code 2011: students wanted!

Is needed be an undergrad student to join in the GSoC? 2011/3/21 Andrew Godwin > Hello everyone, > > Django has once again been accepted as one of the participating projects > for Google Summer of Code, and so we're now looking for student projects! > I've taken over the

secret key from file...

I had an idea. >From time to time I find on the Internet a django app source code with secret_key shown. how about creating an secret.key file next to settings.py in main project module, which should be added by developer to .gitignore, .hgignore or equivalent in settings we read key from file

Summer of Code 2011: students wanted!

Hello everyone, Django has once again been accepted as one of the participating projects for Google Summer of Code, and so we're now looking for student projects! I've taken over the role of GSoC administrator from Jannis this year; feel free to email me directly (or catch me on IRC) if you have

Re: Improving Class based views names

On Mar 20, 4:49 am, Carl Meyer wrote: > > Those last five characters in "get_context_data" actually serve quite a > useful purpose, IMO. They clarify that the return value is just the data > that will go into building a context (a dictionary), as opposed to being > the Context

Re: Improving Class based views names

> The names used by the generic views are (as far as I am aware) > internally consistent within the views, and with the old generic > views. The choice to use pk instead of object_id was quite deliberate, > because every object responds to pk, but not necessarily to id. > I don't believe it's

Re: Composite primary keys

On Mar 21, 1:20 pm, Michal Petrucha wrote: > > My suggestion is to create an Index type that can be included in a > > class just like a field can.  The example we've been using would > > then look like: > > > class Foo(Model): > >    x = models.FloatField() > >    y =

Re: Default project layout / directory structure

I suggest this structure: myproject - apps - libs - conf - public - settings.py - urls.py conf: - production.py - test.py - dev.py libs: - all third party modules public: - media - static - admin - django.wsgi each app structure: - admin - backends - commands -

Re: HTTP methods in urls.py

Then forget about ajax.* What I am thinking is to change url dispatcher to create three as many lists as the http methods is GET = () POST = () DELETE = () ... ALL = () And then while parsing an urls.py it appends fitting matches to those lists. When goes request, for example GET, than

Re: Composite primary keys

On Mon, Mar 21, 2011 at 12:33:01AM -0700, Christophe Pettus wrote: > I'd like to make one more pitch for a slightly different > implementation here. My concern with CompositeField isn't based on > the fact that it doesn't map one-to-one with a field in the table; > it's that it doesn't have any

Re: Composite primary keys

Am 21.03.2011 um 08:33 schrieb Christophe Pettus: > I'd like to make one more pitch for a slightly different implementation here. > My concern with CompositeField isn't based on the fact that it doesn't map > one-to-one with a field in the table; it's that it doesn't have any of the >

Re: HTTP methods in urls.py

On Mon, Mar 21, 2011 at 9:09 AM, haras.pl wrote: > It would be nice to have possibility to distinguish a HTTP method in > urls.py. IMHO it would be clearer and more extensible in future for > example: >  ajax ('POST', r'/user/(?P\d+)$', 'views.view2'), >  ajax ('GET',

Re: Composite primary keys

I'd like to make one more pitch for a slightly different implementation here. My concern with CompositeField isn't based on the fact that it doesn't map one-to-one with a field in the table; it's that it doesn't have any of the semantics that are associated with a field. In particular, it

Re: Default project layout / directory structure

On 20 Kov, 22:10, Markus Gattol wrote: > That does not seem to work with pip and virtual environment, does it? > This one doeshttps://github.com/epicserve/django-environment It does work with zc.buildout. -- You received this message because you are subscribed to the