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 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: 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 topics that came up was the role of design and designers within the Django community. We talked about the fact there's been some frustration lately over our general lack of motion on UI/UX issues. Adrian pointed out that one of Django's long-standing principles has been that design is fundamentally something that doesn't work the same was as open source: many eyes may make for shallow bugs, but many hands make for shitty design. So from the very beginning we treated design differently and let one person, Wilson, be in charge. Of course, Wilson had to go and join a startup* that got successful. Stupid success. But we all pretty agreed that we still think the model of having a design BDFL to vest authority on UI/UX issues was a good model. So we talked about people to fill that role, and Idan was the unanimous choice. He's been contributing to Django for a while now, and most of the core developers have worked with him closely in some capacity or another and all have great things to say about him, his work, and his aesthetic. Most importantly, Idan is great at listening to input and criticism, so we feel strongly that he'll be able to take the design input from the community, digest it, and produce great work. I know that generally we try not to operate in a top-down manner -- and most of our other workflow changes over the last few years have been to *divest* individuals of too much power -- so this may come across as a bit weird to some. Fair enough: it's a bit weird to me, too: I wish we could treat design no different than code. But for whatever reason we've seen time and time again that design-by-committee doesn't work, so we're going to keep doing things this way. So welcome, Idan, and best of luck. I'm really excited to see what happens next! Jacob * Rdio, which everyone should use because it's awesome. -- 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.
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 their needs." -- The book of Django, 22:4 Recently, I was approached by the core team about joining them to help address design issues within Django. I'm excited to announce that I've accepted! I've long felt that one of Django's greatest assets was Wilson's involvement early in the development of Django. It led to a sensible separation between the concerns of python and frontend developers, a template language that is (warts and all) a pleasure to use, and an admin interface which was light-years ahead of its time. In the same way that good documentation and tests emit a pleasing smell for passing developers, these features make Django pleasing for designers because they broadcast a message: "your needs are anticipated; your kind is welcome here." Sadly, Wilson is super-busy, and Django hasn't had an in-house designer advocate in a while. From now on, that's me! I'm here to shepherd efforts touching on UI/UX issues with Django, solicit feedback, engage designers, and break up bikeshedding whenever it stands in the way of Getting Things Done. High-Level Goals 1. Figuring out how to best hear the needs of designers in our community, and advocating for solutions which address those needs inside Django. 2. Figuring out how to attract a community of design-oriented contributors to Django. Right now, contributing to Django is really about contributing _code_ to Django; everything from the tools to the process are geared towards the sensibilities of developers. I'd like to find a system that will facilitate the collection of feedback from the community of designers using Django. Furthermore, there's no reason why we can't foster a vibrant community of designer contributors alongside the existing code contributors. This is an opportunity for Django to lead the way in showing that the efforts of designers are welcome (and sorely needed) in the open- source world. Some Practical Tasks The Admin - The most obvious user-facing aspect of Django is the admin. It is getting long in the tooth, and I've been witness to several fruitless attempts to initiate a refactor. The truth is that the admin is a relatively large chunk of code which (in the main) "just works". Simply ignoring it while starting a ground-up rewrite is a recipe for two failures. Incremental improvements and bugfixes are the way forward on this. A fresh coat of paint for the admin could count as an incremental, though cosmetic, improvement. That being said, it's time to start considering what a rethought admin might look like -- less in terms of visual look'n'feel, more in terms of what audience the admin serves, what use-cases it should try to address, and how best to serve that audience and those use-cases. I have some thoughts on the matter (which I'll share in a separate thread), but this is an opportunity to get UI and UX contributors to the table. Whether and how to rewrite the admin is a decision we can only make after we have a good idea of where we want to go. To that end, I'll be setting up some tools for collecting feedback over the next few days, and will announce them here. Learning from existing efforts in this space (Grappelli and django-admin-tools spring to mind) is a pretty good place to start. Finally, I'm skepctical that a "newadmin" can be realistically completed in the 1.4 timespan. With the exception of incremental improvements, the newadmin process is a long-term thing, which means we need to think about how it can be developed without interfering with Django's release cycle. Forms - Another topic ripe for some love is Django's forms API; it is an area where the bright line between Python and frontend code gets blurry. Form widgets are a good example of this: their HTML is hardcoded in a Python file, replacing them requires writing more Python, and they default to XHTML-style tags, causing conflicts for sites with non- XHTML DOCTYPEs. I'd like to make this a goal for 1.4; there are already some great developments in this space: * http://groups.google.com/group/django-developers/browse_thread/thread/7cc4279367c0a3f0 * https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas Endnote === This is a beginning; obviously the list of issues I haven't written about eclipses those above. Take this opportunity to get your wishlists in order. If you've got a relevant project that I've neglected to mention, don't get upset. Keep an eye on the -dev mailinglist for announcement of resources we'll be using to track existing code and new ideas. Finally, if you know of somebody that might be interested in contributing to Django in a design capacity, ple
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 have any of the
> semantics that are associated with a field. In particular, it can't be:
>
> - Assigned to.
> - Iterated over.
> - Or even have a value.
Obviously there's no code here yet, so we don't know exactly. I'd also
be -1 on an implementation of a CompositeField that didn't have those
values. However, it's reasonably easy to come up with a CompositeField
that is assignable, iterable, and has values. Here's the basics::
class CompositeField(object):
def __init__(self, *fields):
self.fields = fields
def contribute_to_class(self, cls, name):
nt_name = "%s_%s" % (cls.__name__, name)
nt_fields = " ".join(f.name for f in self.fields)
self.nt = collections.namedtuple(nt_name, nt_fields)
setattr(cls, name, self)
def __get__(self, instance, owner):
if instance:
return self.nt._make(getattr(instance, f, None) for f
in self.nt._fields)
raise AttributeError("Composite fields only work on instances.")
def __set__(self, instance, value):
for (field, val) in zip(self.nt._fields, value):
setattr(instance, field, val)
It works, too::
class Person(models.Model):
first_name = models.CharField(max_length=100)
last_name = models.CharField(max_length=100)
name = CompositeField(first_name, last_name)
# ...
>>> p = Person(first_name="Jacob", last_name="KM")
>>> p.name
: Person_name(first_name='Jacob', last_name='KM')
>>> p.name.last_name
: 'KM'
>>> p.name = ("John", "Doe")
>>> p.last_name
: 'Doe'
>>> for f in p.name:
..: print f
..:
..:
John
Doe
Fields even sorta get saved correctly to the DB with just these few
lines of code. Of course there's a lot missing here to correctly
handle actual composite keys -- this tiny example won't work in
querysets, for example -- but the basics of the Python-side behavior's
right there.
> My suggestion is to create an Index type that can be included in a class just
> like a field can.
I think we're talking slightly different concerns here: I'm mostly
interested in the Python-side API, and to my eyes a composite field
matches more closely what's happening on the Python side of things.
Python's not generating an index, after all, so using something called
"index" for compositing multiple attributes together seems weird to
me. But at the DB level, "index" makes perfect sense. Thing is, we've
always tried to make Django's APIs behave well in Python *first*, and
then think about the DB concerns. And again, to me "composite field"
matches more closely the behavior we want out of the Python side of
things.
All that said, there's a lot to like about your Index proposal.
Perhaps there's a way we can merge these two things together somehow?
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-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: 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
from the filesystem.
For the base installation the compromise of the settings.py actually isn't
all that bad. MySQL defaults to listening only on localhost and the database
user is mapped to localhost if you follow the tutorial. Memcache is a
non-default addition, and IIRC also defaults to localhost. If I understand
how it works the compromise of the SECRET_KEY alone doesn't put you in
serious hot water unless the attacker can also intercept traffic. This leads
me to the conclusion that a novice users really doesn't need to worry about
heavily securing the values in settings.py until the are ready to grow their
setup.
That said, an automated tool to write a secret key to the file system and
update settings.py to load it could make sense as a way to help users bridge
the gap between the simple and moderately complex deployments.
Matthew
On Mon, Mar 21, 2011 at 13: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
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> On Mar 21, 5:07 pm, Kristaps Kūlis wrote:
> > "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 credentials - in many cases memcache is unprotected .
> >
> > I think docs should be updated to reflect sensitive settings.py
> > variables, which are confidential and provide "best practices" way
> > ({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
> > command to generate adequate strenght / randomness secret would be
> > beneficial .
>
> --
> 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: 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 don't share it with anybody. I usually keep the generated default in VCS, so that anyone other team members don't have to put it in their localsettings.py. Staging and production servers have their own settings anyway, so it's not really a problem. I'm not sure what exactly are you proposing. Do you want to change the default project template or the docs ? -- Łukasz Rekucki -- 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: 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 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 credentials - in many cases memcache is unprotected .
>
> I think docs should be updated to reflect sensitive settings.py
> variables, which are confidential and provide "best practices" way
> ({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
> command to generate adequate strenght / randomness secret would be
> beneficial .
--
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: 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 dictionary), as opposed to being >> the Context or RequestContext object itself, which is what I'd expect >> from a method named "get_context". > > Good point. I might be splitting hairs, but _data isn't clear enough - > both a dict and a Context objects satisfy `data`. Looking at > RequestContext code, I found __init__ gets a `dict` parameter, so how > about making it get_context_dict? Sure - except that these decisions were made several months ago, and these kinds of considerations needed to have been raised then. We've had a beta and an RC release with these names, and will have 1.3 any time now; there's simply zero chance that we'll break things for everyone who's already started working with CBVs in order to make tiny improvements to method names. Carl -- 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: 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 are easy to parse with the ConfigParser in Python. You can simply
parse it in your settings.py:
import ConfigParser
config = ConfigParser.ConfigParser()
config.readfp(open('../settings.cfg'))
SECRET_KEY = config.get('secret', 'key')
--
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: 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 credentials - in many cases memcache is unprotected .
I think docs should be updated to reflect sensitive settings.py
variables, which are confidential and provide "best practices" way
({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
command to generate adequate strenght / randomness secret would be
beneficial .
Kristaps Kūlis
On Mon, Mar 21, 2011 at 4:59 PM, Matt Harasymczuk wrote:
> 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 to SECRET_KEY and we go as usual.
>
> SECRET_KEY = open("secret.key").read()
>
> then, a django-admin startproject should give a warning "add
> secret.key to your version management system ignore file", it should
> automatically put generate secret phrase to this file
>
> what about downloading an app from the Internet
>
> manage.py createsecret
> will ask if we want to generate new secret file
> if file exists, and overwrite an existing one
>
> dajngo has to be pythonic, therefore
> cat secretkey.py
>
> SECRET_KEY = "as it goes usual"
>
> and in settings file
>
> from .secretkey import *
>
>
> What do you think?
> IMHO both this ways are good
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> 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: 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 >> 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 >> any problems or want to discuss something about the program. >> >> For those who aren't aware: Summer of Code is Google's program to pay >> students to work on open source projects over the summer. It's an >> excellent >> chance for you to get involved in open source without worrying about >> having to get a summer job for income; Django have been doing GSoC >> since 2006 and several core committers are former GSoC students. >> >> For more details about Summer Of Code, including the timeline, >> payment amounts, and how students are expected to participate, >> check out Google's FAQ: >> >> >> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs >> >> >> If you're interested in working on Django as part of GSoC please >> read this whole email (much thanks to both Jannis and Jacob for >> providing previous iterations of much of this text). >> >> Important dates >> --- >> >> The whole timeline can be found on Google's GSoC site, but there's a >> couple of >> important dates you should be aware of right now: >> >> The student application period opens March 28th and ends April 8th >> (19:00 UTC). >> >> Remember, the April 8th deadline is a *hard* deadline: no applications >> filed >> late will be considered. This means you've got a little more than two >> weeks to >> prepare your application, so the time to start is *right now*. >> >> Picking a project >> - >> The first thing you need to do is choose something to work on. Hopefully >> if >> you're reading this you've already got an idea; if not, there's some >> ideas at >> >>http://code.djangoproject.com/wiki/SummerOfCode2011 >> >> However, if you just pick something there and throw together a quick >> application, you're going to get rejected immediately. There's a lot >> more to >> choosing a project that just throwing something together. >> >> We've found over the past years that the pickier we are about application >> quality, the better the final projects are. Because we want success this >> year, >> we're going to be exceedingly picky about only accepting good >> applications, so >> it's vital that you put your best foot forward. Here's how: >> >> Think of the process as applying for a job. You're trying to convince us >> that you: >> >>(a) understand the problem you're attempting, and >> >>(b) have some chance of achieving something realistic in the 12 week >>period you've got to work. >> >> This can be hard, particularly for people haven't been involved in Django >> development before; while some projects require a history of involvement >> before >> applying, we let anybody apply. So it's really *now* that you want to >> start >> getting involved. You have to put in a little bit of work to work out >> how your >> problem might be approached, or what the current problems are. Don't >> just pick >> something from the ideas page -- you could also look through Trac and >> view the >> tickets grouped by component and see if there's a bunch of things in a >> similar >> area that suggests something needing more holistic attention. >> >> Most importantly, though, when you have some kind of idea, start a >> discussion >> on django-developers. This will let us help you understand what you're up >> against, and it'll help us see that you've got the knowledge to tackle the >> problem. It also helps if you mark the discussion subject with [GSoC], so >> we >> can easily see that you want feedback relatively quickly. >> >> The applications that have been most successful in the past -- in terms of >> producing working code at the end of the period, rather than just being >> accepted -- are those where the applicants have engaged a bit ahead of >> time to >> see if their ideas stand up to review and/or tweak those ideas a bit. >> >> Once you've had one of these discussions, *then* you're in a position to >> write >> an application that can lay out your cunning plan and point to a >> discussion >> showing it kind of holds up under scrutiny. We have much more confidence >> voting for a student who's done the preparation than somebody with no >> history >> whatsoever. Many SoC students are only starting to get into Django, which >> means you have to do some work here and get a feeling for what >> you're up against. >> >> In short, the application isn't a "convince us to let you work on this >> for the >> summer" as much as "convince us you understand the problem you're >> proposing to work on and that your solutio
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 role of GSoC administrator from Jannis this year; > feel free to email me directly (or catch me on IRC) if you have > any problems or want to discuss something about the program. > > For those who aren't aware: Summer of Code is Google's program to pay > students to work on open source projects over the summer. It's an excellent > chance for you to get involved in open source without worrying about > having to get a summer job for income; Django have been doing GSoC > since 2006 and several core committers are former GSoC students. > > For more details about Summer Of Code, including the timeline, > payment amounts, and how students are expected to participate, > check out Google's FAQ: > > > http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs > > > If you're interested in working on Django as part of GSoC please > read this whole email (much thanks to both Jannis and Jacob for > providing previous iterations of much of this text). > > Important dates > --- > > The whole timeline can be found on Google's GSoC site, but there's a > couple of > important dates you should be aware of right now: > > The student application period opens March 28th and ends April 8th > (19:00 UTC). > > Remember, the April 8th deadline is a *hard* deadline: no applications > filed > late will be considered. This means you've got a little more than two > weeks to > prepare your application, so the time to start is *right now*. > > Picking a project > - > The first thing you need to do is choose something to work on. Hopefully if > you're reading this you've already got an idea; if not, there's some > ideas at > >http://code.djangoproject.com/wiki/SummerOfCode2011 > > However, if you just pick something there and throw together a quick > application, you're going to get rejected immediately. There's a lot > more to > choosing a project that just throwing something together. > > We've found over the past years that the pickier we are about application > quality, the better the final projects are. Because we want success this > year, > we're going to be exceedingly picky about only accepting good > applications, so > it's vital that you put your best foot forward. Here's how: > > Think of the process as applying for a job. You're trying to convince us > that you: > >(a) understand the problem you're attempting, and > >(b) have some chance of achieving something realistic in the 12 week >period you've got to work. > > This can be hard, particularly for people haven't been involved in Django > development before; while some projects require a history of involvement > before > applying, we let anybody apply. So it's really *now* that you want to start > getting involved. You have to put in a little bit of work to work out > how your > problem might be approached, or what the current problems are. Don't > just pick > something from the ideas page -- you could also look through Trac and > view the > tickets grouped by component and see if there's a bunch of things in a > similar > area that suggests something needing more holistic attention. > > Most importantly, though, when you have some kind of idea, start a > discussion > on django-developers. This will let us help you understand what you're up > against, and it'll help us see that you've got the knowledge to tackle the > problem. It also helps if you mark the discussion subject with [GSoC], so > we > can easily see that you want feedback relatively quickly. > > The applications that have been most successful in the past -- in terms of > producing working code at the end of the period, rather than just being > accepted -- are those where the applicants have engaged a bit ahead of > time to > see if their ideas stand up to review and/or tweak those ideas a bit. > > Once you've had one of these discussions, *then* you're in a position to > write > an application that can lay out your cunning plan and point to a discussion > showing it kind of holds up under scrutiny. We have much more confidence > voting for a student who's done the preparation than somebody with no > history > whatsoever. Many SoC students are only starting to get into Django, which > means you have to do some work here and get a feeling for what > you're up against. > > In short, the application isn't a "convince us to let you work on this > for the > summer" as much as "convince us you understand the problem you're > proposing to work on and that your solution has a chance of working > and being accepted by the core body of developers". > > Our goal this year is for *every single project* to result in code that > gets > committed back to Django. We'll accomplish this goal by *
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 to SECRET_KEY and we go as usual.
SECRET_KEY = open("secret.key").read()
then, a django-admin startproject should give a warning "add
secret.key to your version management system ignore file", it should
automatically put generate secret phrase to this file
what about downloading an app from the Internet
manage.py createsecret
will ask if we want to generate new secret file
if file exists, and overwrite an existing one
dajngo has to be pythonic, therefore
cat secretkey.py
SECRET_KEY = "as it goes usual"
and in settings file
from .secretkey import *
What do you think?
IMHO both this ways are good
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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.
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 any problems or want to discuss something about the program. For those who aren't aware: Summer of Code is Google's program to pay students to work on open source projects over the summer. It's an excellent chance for you to get involved in open source without worrying about having to get a summer job for income; Django have been doing GSoC since 2006 and several core committers are former GSoC students. For more details about Summer Of Code, including the timeline, payment amounts, and how students are expected to participate, check out Google's FAQ: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs If you're interested in working on Django as part of GSoC please read this whole email (much thanks to both Jannis and Jacob for providing previous iterations of much of this text). Important dates --- The whole timeline can be found on Google's GSoC site, but there's a couple of important dates you should be aware of right now: The student application period opens March 28th and ends April 8th (19:00 UTC). Remember, the April 8th deadline is a *hard* deadline: no applications filed late will be considered. This means you've got a little more than two weeks to prepare your application, so the time to start is *right now*. Picking a project - The first thing you need to do is choose something to work on. Hopefully if you're reading this you've already got an idea; if not, there's some ideas at http://code.djangoproject.com/wiki/SummerOfCode2011 However, if you just pick something there and throw together a quick application, you're going to get rejected immediately. There's a lot more to choosing a project that just throwing something together. We've found over the past years that the pickier we are about application quality, the better the final projects are. Because we want success this year, we're going to be exceedingly picky about only accepting good applications, so it's vital that you put your best foot forward. Here's how: Think of the process as applying for a job. You're trying to convince us that you: (a) understand the problem you're attempting, and (b) have some chance of achieving something realistic in the 12 week period you've got to work. This can be hard, particularly for people haven't been involved in Django development before; while some projects require a history of involvement before applying, we let anybody apply. So it's really *now* that you want to start getting involved. You have to put in a little bit of work to work out how your problem might be approached, or what the current problems are. Don't just pick something from the ideas page -- you could also look through Trac and view the tickets grouped by component and see if there's a bunch of things in a similar area that suggests something needing more holistic attention. Most importantly, though, when you have some kind of idea, start a discussion on django-developers. This will let us help you understand what you're up against, and it'll help us see that you've got the knowledge to tackle the problem. It also helps if you mark the discussion subject with [GSoC], so we can easily see that you want feedback relatively quickly. The applications that have been most successful in the past -- in terms of producing working code at the end of the period, rather than just being accepted -- are those where the applicants have engaged a bit ahead of time to see if their ideas stand up to review and/or tweak those ideas a bit. Once you've had one of these discussions, *then* you're in a position to write an application that can lay out your cunning plan and point to a discussion showing it kind of holds up under scrutiny. We have much more confidence voting for a student who's done the preparation than somebody with no history whatsoever. Many SoC students are only starting to get into Django, which means you have to do some work here and get a feeling for what you're up against. In short, the application isn't a "convince us to let you work on this for the summer" as much as "convince us you understand the problem you're proposing to work on and that your solution has a chance of working and being accepted by the core body of developers". Our goal this year is for *every single project* to result in code that gets committed back to Django. We'll accomplish this goal by *rejecting* applications that don't show us good odds of success. What a good proposal looks like --- Once you've got some discussion done, and have a handle on the task, you'll need to submit your proposal on the GSoC website (http://www.google-melange.com/).
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 or RequestContext object itself, which is what I'd expect > from a method named "get_context". > Good point. I might be splitting hairs, but _data isn't clear enough - both a dict and a Context objects satisfy `data`. Looking at RequestContext code, I found __init__ gets a `dict` parameter, so how about making it get_context_dict? Benny -- 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: 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 backward compatible with the current generic views - http://docs.djangoproject.com/en/1.2/ref/generic-views/#django-views-generic-list-detail-object-detail. IMHO, it's the other way around: every viewable object got to have some kind of an id, but not necessarily a pk. In the case an object comes from the db the object_id is the primary key, in case I choose to override the get_object method I can use the object_id to retrieve an object from a dataset that has no primary keys. > Compatibility with third party libraries isn't really a consideration > unless the general community has converged on a convention which a new > Django feature has blindly ignored. In this case, I would argue that > pk is the convention, and Django-backlinks is in need of an update. hmm, I was under the impression `object_id` is the convention for urls and views while pk is used for models. Maybe, I'm wrong, but searching the docs, I found it was referenced by admin, contenttypes, comments and of course generic views. Benny -- 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: 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 = models.FloatField() > > a = models.ForeignKey(A) > > b = models.ForeignKey(B) > > > coords = models.CompositeIndex((x, y)) > > pair = models.CompositeIndex((a, b), primary_key=True) > > > We could have FieldIndex (the equivalent of the current > > db_index=True), CompositeIndex, and RawIndex, for things like > > expression indexes and other things that can be specified just as a > > raw SQL string. > > > I think this is a much better contract to offer in the API than one > > based on field which would have to throw exceptions left and right > > for most of the common field operations. > > I don't see how ForeignKeys would be possible this way. > In much the same way: class FooBar(Model): a = models.ForeignKey(A) b = models.ForeignKey(B) pair = models.ForeignKey(Foo, fields=(a, b)) Note that this is very close to what SQL does. If you have a composite unique index or composite foreign key you define the fields and then the index / foreign key. Though I don't know how much value that argument has in this discussion. You could add some DRY and allow a shortcut: class FooBar(Model): pair = models.ForeignKey(Foo) # a and b are created automatically. Now, to make things work consistently pair should be a field. But on the other hand when using a ModelForm, the pair should probably not be a field of that form. This is more clear in an example having a (city, state, country) primary key. These should clearly be separate fields in a form. In my opinion, if the composite structures are called fields or something else isn't that important. There are cases where composite structures behave like a field and some cases where they do not. The main problem is how the composite structures should behave in ModelForms and serialization, should they be assignable, how the relate to model __init__ method, should they be in model fields iterators, how they are used in QuerySets and so on. When these questions are answered it is probably easier to answer if the composite structures should be called fields or something else. - Anssi -- 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: 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 - context_processors - decorators - feeds - forms - management - managers - middleware - models - signals - sitemaps - templates - templatetags - tests - urls.py - views most of above are unnecessary for simple project, so I suggest to add a switch to manage.py startapp to do this. I am suggesting that app should have directories not files... When you develop large app (CRM) you have to write tens of models, with overriding saves, __unicode__, Meta and custom methods it becomes hard to read and maintain I solve this by adding app_label to each of my models in separate files and models/__init__.py imports all models. It works like a charm. I think it should be by default :} I created skel/django/project and skel/django/app folders, where I have this file structure when I start project I simply copy folder, rename it, and adjust -- Matt Harasymczuk www.matt.harasymczuk.pl -- 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: 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 dispatcher lookup regexp
pattern in GET lists,
if its find, we have a hit, if not go to ALL dict, if it isn't there
throw 404
This Classed based view method is good, but you have to create one
abstract view and then inherit in all your views to do so. Unless you
want to write a lot of boilerplate code per view
--
Matt Harasymczuk
www.matt.harasymczuk.pl
On Mar 21, 8:44 am, Russell Keith-Magee
wrote:
> 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', r'/user/(?P\d+)$', 'views.view2'),
> > ajax ('DELETE', r'/user/(?P\d+)$', 'views.view2'),
> ...
> > I think this is a good way of getting rid of nested ifs in each view:
>
> > if request.is_ajax:
> > #do stuff
> > else:
> > if request.method == "POST":
> > #do something
> > else:
> > #do else
>
> > Hence my true code is almost two indents inside those boilerplate if
> > structure. Which is always the same... it takes a lot of python beauty
> > and readibility from code.
>
> While I can see where this request comes from, I agree with the triage
> review that the ticket has received -- that this isn't necessary. This
> is for three reasons:
>
> * As noted on the ticket What you are describing can already be done
> with class-based generic views, and a class-based resource structure
> is a much better way of gathering concerns than three lines in a URL
> config file
>
> * Even if you don't want to use class-based resources, you could
> easily generate a wrapper function to direct to subviews as required
> based on request methods:
>
> def dispatched_view(get_view=None, post_view=None):
> def _view(request, *args, **kwargs):
> if request.method == "POST":
> return post_view(request, *args, *kwargs)
> return get_view(request, *args, **kwargs)
> return _view
>
> and then, in your urls.py:
>
> url(r'/user/(?P\d+)$', dispatched_view(GET=get_view,
> POST=post_view))
>
> Your definition of ajax_view could be a lot more complex than that,
> including handling for the is_ajax flag, other HTTP verbs, and so on.
>
> * Lastly, even if the previous two approaches didn't exist, the
> proposal you have made requires a pretty egregious duplication of
> regular expressions. This is both a performance hit (since you need to
> match the same regular expression pattern multiple times), as well as
> a potential source of error (since you are repeating yourself).
>
> 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-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: 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 of the semantics that are associated > with a field. In particular, it can't be: > > - Assigned to. > - Iterated over. > - Or even have a value. I disagree. The CompositeField would need to have a value to be able to implement a ForeignKey pointing to a modedel with a composite primary key. The CompositeField itself would be just a proxy to the actual atomic fields. You should be able to assign a tuple (or namedtuple) to it, specifying the actual values for the fields. Similarly, you'll be able to retrieve its value which is a tuple or a namedtuple. This way, the following code would work for composite primary keys the same way it works for simple keys: class CompositeModel(models.Model): a = models.IntegerField() b = models.IntegerField() key = models.CompositeField((a, b), primary_key=True) class ReferencingModel(models.Model): cm = models.ForeignKey(CompositeModel) cminstance = CompositeModel.objects.get(something) newref = ReferencingModel() newref.cm = cminstance.pk > 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 = models.FloatField() >a = models.ForeignKey(A) >b = models.ForeignKey(B) > >coords = models.CompositeIndex((x, y)) >pair = models.CompositeIndex((a, b), primary_key=True) > > We could have FieldIndex (the equivalent of the current > db_index=True), CompositeIndex, and RawIndex, for things like > expression indexes and other things that can be specified just as a > raw SQL string. > > I think this is a much better contract to offer in the API than one > based on field which would have to throw exceptions left and right > for most of the common field operations. I don't see how ForeignKeys would be possible this way. Michal Petrucha signature.asc Description: Digital signature
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 > semantics that are associated with a field. In particular, it can't be: > > - Assigned to. > - Iterated over. > - Or even have a value. You would be able to use composite fields normally (as in "normal django field"): >>> foo = Foo.objects.create(coords=(0, 0)) >>> foo.coords (0, 0) >>> foo.coords = (4, 2) >>> foo.coords.x # == foo.x == foo.coords[0] 4 Sidenote:: Subclassing the default implementation of composite field values should be easy: >>> type(foo.coords) >>> foo.coords.length 4.4721359549995796 >>> foo.coords += foo.velocity __ Johannes -- 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: 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', r'/user/(?P\d+)$', 'views.view2'),
> ajax ('DELETE', r'/user/(?P\d+)$', 'views.view2'),
...
> I think this is a good way of getting rid of nested ifs in each view:
>
> if request.is_ajax:
> #do stuff
> else:
> if request.method == "POST":
> #do something
> else:
> #do else
>
> Hence my true code is almost two indents inside those boilerplate if
> structure. Which is always the same... it takes a lot of python beauty
> and readibility from code.
While I can see where this request comes from, I agree with the triage
review that the ticket has received -- that this isn't necessary. This
is for three reasons:
* As noted on the ticket What you are describing can already be done
with class-based generic views, and a class-based resource structure
is a much better way of gathering concerns than three lines in a URL
config file
* Even if you don't want to use class-based resources, you could
easily generate a wrapper function to direct to subviews as required
based on request methods:
def dispatched_view(get_view=None, post_view=None):
def _view(request, *args, **kwargs):
if request.method == "POST":
return post_view(request, *args, *kwargs)
return get_view(request, *args, **kwargs)
return _view
and then, in your urls.py:
url(r'/user/(?P\d+)$', dispatched_view(GET=get_view, POST=post_view))
Your definition of ajax_view could be a lot more complex than that,
including handling for the is_ajax flag, other HTTP verbs, and so on.
* Lastly, even if the previous two approaches didn't exist, the
proposal you have made requires a pretty egregious duplication of
regular expressions. This is both a performance hit (since you need to
match the same regular expression pattern multiple times), as well as
a potential source of error (since you are repeating yourself).
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-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: 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 can't be: - Assigned to. - Iterated over. - Or even have a value. 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 = models.FloatField() a = models.ForeignKey(A) b = models.ForeignKey(B) coords = models.CompositeIndex((x, y)) pair = models.CompositeIndex((a, b), primary_key=True) We could have FieldIndex (the equivalent of the current db_index=True), CompositeIndex, and RawIndex, for things like expression indexes and other things that can be specified just as a raw SQL string. I think this is a much better contract to offer in the API than one based on field which would have to throw exceptions left and right for most of the common field operations. -- 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: 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 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.
