On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> So, is it possible to have an overview of the _active_ "core developers"
> and "other contributors"?
There is no such list or overview.
Again, I think that maintaining such lists is a level of bureaucracy
which would not provide the project
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote:
> So, why not create an option for "startproject", to keep everyone (you,
> me, the unexperienced, the experienced) happy? Flexibility and freedom
> of choice is a nice thing:
OK, now I have to start questioning credibility. "Accomodate novice
On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Fixed, is now ticket http://code.djangoproject.com/ticket/2070
Should've read this before I read that ticket.
Or woken my brain up.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~
On 6/2/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> One issue would be what to name this
> more-critical-than-CriticalValidationError validation error.
FatalValidationError.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~---
In response to a comment I got the other day on my blog, I've written
a first draft of a document detailing, from start to finish, how
Django processes a request. I'd love to get feedback, suggestions and
corrections on this so I can refine it into a really useful write-up,
so if you have a few mi
On 6/14/06, SmileyChris <[EMAIL PROTECTED]> wrote:
> I don't want to go reopening the ticket, but couldn't this still be
> useful functionality?
Well, I can certainly see Adrian's point in that ticket; Django really
isn't meant for handling static files, which is why there are huge
warnings all o
On 6/15/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> What would you rather have:
> "Help, help! How do I turn off escaping?"
I don't know... memories are stirring of my PHP days and the horror of
magic_quotes...
--
"May the forces of evil become confused on the way to your house."
-- George
I've had some thoughts bouncing around in my head for a while about
Django's documentation, and I think it's time to finally commit them
to tangible form, so here goes:
Compared to either the standard open-source project or the standard
piece of web software, Django's documentation is good. Reall
On 6/16/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> To reiterate: templates shouldn't need to care about escaping. Django
> *in particular* uses an intentionally dumbed down template system
> that is supposed to be easy for non-programmers, which includes the
> notion that little mistakes in
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> yes - we are all ears
Meh. The book-buying is a giveaway.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~~---~--~~
You received this message because
On 6/19/06, Matias Hermarud Fjeld <[EMAIL PROTECTED]> wrote:
> I have submitted a patch to ticket#2197[0]. Any comments? Does anyone
> else think this is useful to have in django?
It's a useful thing, but...
We've got a Summer of Code project working on a true
search-engine-like system to integr
On 6/19/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Will the Summer of Code project include some kind of fall-back for
> when a proper full-text indexing system isn't available? (Something
> trivial based on LIKE queries). For small sites the .search() method
> would be very useful.
Jacob's m
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> then nobody got it - because *that* is not a framework - it is an
> application server, which is a totally different kettle of fish
Yeah. I was thinking "Booby on Whales".
Some things have a learning curve. Zope has a learning asymptote.
On 6/19/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
> It felt like a db error, because of *where* it was breaking, but I've
> not yet looked into the ORM layer, and didn't have time to start
> digging.
This feels like a reawakening of some old bugs that had to do with
matching dates in SQLite; I fo
On 6/20/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I've gotta say, I don't like the concept of auto-escaping on by
> default. I'd rather not have the framework automatically munging my
> data behind my back: it'd be a case of the same type of magic that we
> removed in the magic-removal bran
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I haven't used the magical versions of Django, but I regard the magic that
> has magically imported models a different thing. In every framework things
> happen automatically, and just calling it "bad magic" is something that
> might result
The more I think about it, the more I find I have two objections to
the auto-escaping stuff.
1. A philosophical objection. One thing Django does, and does pretty
well IMHO, is encourage best practices. Pretty much every aspect of
Django, from the overall architecture of the framework to the worki
And just to clarify, when I talk about implementing the escaping
system, I mean a block tag which escapes everything inside itself as
appropriate. Nothing more, nothing less.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~---
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> Then again, how often do you *want* to allow your users to put HTML
> and JS in and allow it to be executed? Not often, I imagine.
This depends completely on the type of application. Some applications
will have very little HTML input by users, b
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> This is my preferred choice, as well, but I'm not well-versed enough
> in the internals of Django to know if allowing empty models can
> create other problems outside of the admin interface. If anyone could
> point me to the relevant areas of cod
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> Oh - I haven't heard of the magic_quotes fiasco. Do you have any
> links or more information about this? If it blew up for the PHP
> folks, I think I'd be prone to changing my position on the issue.
The magic_quotes setting in PHP is a "feature"
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, come on, that's a completely different thing than auto-escaping
> of variables in the template. I had no idea php is/was *that* brain-
> dead (*shiver*)
The problem of suddenly having to figure out ways to tell whether
you're dealing w
On 6/22/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Now, I don't like to put the whole burden into the input validation,
And nobody's really suggesting that we should; we already provide a
template filter for sanitizing on output, and a block tag for doing
the same seems like a decent idea.
On 6/22/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> I disagree that it's easy to write that kind of validator function -
> and I think trying to do so is a mistake. What if I want to post a
> comment on a forum like this?
Then you'd get caught by the validator.
Thinking about the implication
On 6/22/06, waylan <[EMAIL PROTECTED]> wrote:
> Some are suggesting that this text should be escaped before being
> written to the db. It is true that the above text should be rendered as
> follows in html/xml documents:
I don't think we should escape before storing. I think we should
*validate*
On 6/22/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Ouch! Sometimes this Django thing changes too fast :-)
Though the default 500 view has since gone back to a standard Context.
As Adrian explained in the commit message, this is to avoid having
context processors in the 500 view raise somethin
On 7/2/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> I agree that explicitness is better. But I think implicit filtering
> here is not that bad for two reasons. The first is, as I said, it is
> the rule not the exception. The second is that it makes it extremely
> easy to start your application
On 7/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> You are always going to have to specify the weblog_id (or whatever
> condition you are filtering on) somewhere and you are going to have to
> put in some logic somewhere to convert a request into the right
> weblog_id. The latter can be do
On 7/11/06, Iain Duncan <[EMAIL PROTECTED]> wrote:
> If need be, I don't mind working on my own hack of the delete function
> for the admin interface for now. My questions:
Patches would be gratefully reviewed.
> Is there are news on how this issue is likely to be handled?
Not that I'm aware of
On 7/11/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> I need to test this properly and fill in the mappings, but the gist of
> the approach should be clear. When that's done, unless someone has an
> objection, I'll file a patch against
The structure and logic look good; my only worry is that this
On 7/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> If you allow Null, this is in my opinion a strong indication that
> deleting the other end should not cascade but set Null.
Whatever the default ends up being, whether it stays cascading or
moves to restricting, assuming that allowing NULL
On 7/16/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> What does this add?
> ---
> (1) An "autoescape" template tag that turns automatic escaping on or off
> throughout its scope.
OK.
> (2) A "noescape" filter that marks its result as safe for use without
> further escaping
On 7/16/06, Bryan Kyle <[EMAIL PROTECTED]> wrote:
> This solution seemed to be only half a solution. While the solution
> will work for applications that only need to connect to one database at
> a time, it will not work for me where I need to have multiple
> connections (for multiple documents)
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> Not only for MySQL would this be handy, for other backends as well. I think
> for PostgreSQL the inheritance feature would need this too.
How so? Postgres doesn't have multiple storage engines like MySQL
does; a Postgres table is a Postgr
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> This storage engine choice was only an example. There are lots of other
> options which can be set per table.
> As Honza replied, this is not MySQL specific and PostgreSQL as well as other
> DBMS accept options like these.
But pretty much
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> No.. This is about table options. All of them! Not only storage engine
> choice. All of the table options anyone can imagine.
I still feel like it's way too much of a special case to try to do
this; the proposed option of an "anything goe
On 7/20/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> 8. Navigate to the root page, the "archive view".
> PROBLEM: There are no years listed under the year list (i.e. no
> objects in "date_list"). The docs say that "date_list" contains "A
> list of datetime.date objects representing all years that h
On 7/21/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> comes up 4-5 times a day at least on IRC, most common desire is to
> extend auth.User
Which I've never understood. Subclassing User, even when model
inheritance works again, will be probably the most difficult, least
efficient and least r
On 7/22/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> What is the current wisdom on OneToOne? Will it be finalized soon? Ever?
As I understand it from a conversation I had the other day, nothing
whatsoever will happen until subclassing is straightened out. At that
point we'll move to recommending
On 7/22/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Underlying behavior? So, is it basically safe to use a OneToOneField
> and the API, though not guaranteed to be consistent, is likely to
> just require tweaking? In other words, while underlying behavior
> might change, it'll look roughly equiv
On 7/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> how is this outside the scope?
As I said on IRC, I don't really feel like handling background
maintenance jobs is something that's in scope for a web application
framework. If an application needs periodic maintenance, it's easy
enough to wrap
On 7/24/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Probably, this is more a question for the user list.
Actually, after around sixteen hours of off and on fiddling with
things via IRC, I suggested she ticket it and post here to see if any
of the rapid-fire Django bug squashing team at OSCON
On 7/25/06, Andy Robinson <[EMAIL PROTECTED]> wrote:
> I am with Ian on this.
If I'm understanding both of you correctly, what you're proposing is
several orders of magnitude more complex than what Ian has coded up;
Ian's patch just adds a few dispatcher signals and an option to
manage.py to fire
On 7/25/06, wnielson <[EMAIL PROTECTED]> wrote:
> if not self.genres.all():
> try:
>
> genre=Genre.objects.get(name='default') #default genre
> except:
>
On 7/25/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Wouldn't self.genres.all()[:1].count() save the database engine some
> work?
If you go that route, you don't need the count() anymore; slicing
forces the QuerySet to be evaluated.
Doing a SELECT COUNT(*) is pretty cheap, though, and DBs pr
On 7/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> In most databases -- any that use MVCC -- row counts are difficult to
> index, and thus COUNT(*) is usually O(N). MySQL is the big
> exception; it does index row counts and so COUNT(*) in MySQL is O(1).
Bah. Stil getting used to working
On 7/26/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Assign it to me. I have the code written that just about makes this work
> already. So it will be a good reminder to finish it off.
Done (#2430).
While we're on the topic, the docs explicitly advise against doing
'len' on a QuerySet bec
On 7/28/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Scope it per template:
>
> {% extends "base_generic.html" %}
> {% escape %}
>
> This lets people who want auto-escaping, have it, without typing in
> "|escape" everywhere or screwing things up site wide with globals.
Yeah. AFAIK that's pretty
On 7/28/06, Roland van Laar <[EMAIL PROTECTED]> wrote:
> Would it be better to couple it with the mimetype? A text/plain should
> by default not be excaped.
What would be *best* is for there to be no magical implied
escaping/unescaping of anything, only explicit escaping/unescaping
based on a tem
On 7/29/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Maybe the Ubuntu people have it right; stop using version numbers. You
> could probably tag the trunk tonight, call it "django-nuages" and have
> 10k downloads by Monday.
Probably :)
But recent activiy on the timeline looks encouraging for a
On 7/30/06, jws <[EMAIL PROTECTED]> wrote:
> Could someone familiar with the admin give some feedback about the
> possibility of something like this happening? It doesn't seem like this
> would be a huge amount of work to implement. How wrong am I?
My initial thought is that, since this is going
On 7/30/06, jws <[EMAIL PROTECTED]> wrote:
> I am not familiar with this option you speak of. Do you have a link to
> more information?
http://www.djangoproject.com/documentation/model_api/#js
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~--
On 7/30/06, SmileyChris <[EMAIL PROTECTED]> wrote:
> 1. Technically, the view decides how a template is going to be
> displayed, not the template itself. Could the view, therefore, be the
> best place for escaping to happen?
The view decides which template to use, and what variables will be
made
On 8/3/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> This has been brought up a couple of times. See
> http://code.djangoproject.com/ticket/696, which was marked wontfix,
> reopened, and marked wontfix again. It's clearly not a concern the core
> devs care about.
Considering Malcolm is one of the
On 8/9/06, Linicks <[EMAIL PROTECTED]> wrote:
> 1. Chris, would it be reasonable to move your work to Dojo?
>From the looks of things, that's how he'd implemented it at first; he
then switched to YUI.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
-
On 8/9/06, Chris Long <[EMAIL PROTECTED]> wrote:
> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I kno
On 8/9/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> Ian Clelland and I have been working on a way to address the problem
> that Django FileFields and ImageFields can't be cleared once they've
> been set. We've posted a proposed solution here [1].
This is certainly a long-standing wart in Django, a
On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> 2) How should the affected users be notified? Having read the above
> doc, I think this could use some more detail.
One would hope that anyone who's using Django is subscribed to
django-users and/or watches the Django blog (or that a company w
On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> I can see how a policy like that is "tricky"... What's to keep an evil
> blackhat from subscribing to the very same list so he he knows when to
> get busy cracking sites using the same information?
I've been watching people go round and round
This is a bit long for a ticket writeup, but I wanted to get some
comments on it, so here goes:
The "magic" that still goes on in the templatetag system has been
discussed before on the list[1], and the consensus was that, since
it's relatively invisible and harmless, it's OK for it to stay.
Exc
On 8/11/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
> I'll admit that I haven't really looked into how the admin system
> works post-magic removal but I could work 90% of the extensions I want
> if I could 1. register a callback for changes to a particular model
> and 2. Inject javascript into a p
Back when the magic-removal branch was still going, there were plans
to roll up a bunch of bugfixes against pre-m-r Django (e.g., 0.91) and
do a '0.92' or some other form of final release for the old-style
Django.
Since I just lost about an hour of my life to dealing with a problem
in pre-m-r Dja
On 8/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> As long as it's strictly bug fixes, and no feature additions, that
> sounds fine by me. The reason I say "no feature additions" is that it
> wouldn't be in our best interest to have another competing branch, as
> we did with magic-removal vs
On 8/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yeah, I agree that we should improve the templatetag loading magic.
> What about doing *both* -- improving the docs to note the ImportError
> gotcha, *and* introspecting the ImportError?
Sounds good, though if we introspect the ImportError
On 8/13/06, Jakub Labath <[EMAIL PROTECTED]> wrote:
> 2. Due to time/money reasons I am running a relatively old version of
> django. I realise that by doing that I'm left on my own. However It
> would be nice to be able to go to Trac or somewhere and see all
> security related bugs/fixes so that
On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> The Lawrence guys have mentioned on this list previously that they have
> many different applications they pull together in various projects.
:)
If we couldn't modularize, we wouldn't be able to sell different
"editions" of Ellington.
On 8/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> what about the loaded templatetag-sets and where they are located ?
Template tag libraries already get picked up, and if they've got
docstrings those should be displayed.
--
"May the forces of evil become confused on the way to your hou
On 8/17/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> IMO, the dependency checking is the easy part. In the README or
> something, I say MyCoolApp requires the admin app. It's the
> configuration settings of the admin app that's hairy.
That's what application documentation is for. In theory it's
Something I've noticed that trips up a lot of people, both new Django
users and old, is the way the 'default' argument for model fields
works; there's a disconnect between what it actually does and what
people commonly assume it does, based largely in when the default
value is filled in:
1. The w
On 8/19/06, simonbun <[EMAIL PROTECTED]> wrote:
> I'm well aware that its no problem to use ajax right now by using any
> JS toolkit. My point was that it seems somewhat wasteful to have custom
> JS scripts for the admin generator, and then using a JS toolkit that
> does the same thing.
I submitt
On 8/20/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Metaphorically cutting off both our arms so that we appear
> more aerodynamic is probably not a gain worth making.
That's going in my quotes file.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 8/22/06, Manuel Saelices <[EMAIL PROTECTED]> wrote:
> I patched django for permit abstract classes in a model. My syntax maybe
> doesn't like to someone...
The new and improved model inheritance that Malcolm is working on will
also provide a facility for abstract "base" classes, so I'm thinkin
On 8/21/06, limodou <[EMAIL PROTECTED]> wrote:
> Some points I think are reasonable, for example: django configuration
Text really sucks as a medium for certain kinds of things, so keep in
mind that the fact that it's in email will probably result in this
response sounding much harsher than it wa
On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
> SA provides:
> * connection pooling - since you asked about it, I'll quote from the SA docs:
This is why I said "what comes to mind when I think 'database
connection pooling' isn't something I think belongs in Django."
Maintaining in-process
On 8/22/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> You're taking the original statement out of context. The context was
> the often-heard argument that Django lets you replace any subsystem
> if you prefer using a different library. What's less often-heard is
> that if you do so, you are gi
On 8/22/06, JP <[EMAIL PROTECTED]> wrote:
> I think the problem here is competing definitions of the term
> 'connection pool'. You're using 'connection pool' to mean a connection
> that may be transparently directed to one of N databases (say where
> records 1-100 are on database machine A and
On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote:
> http://www.sqlalchemy.org/docs/adv_datamapping.myt
Some of these examples deal with rather exotic use cases that, I
think, are close to the edge of what ORM can reasonably do before the
abstraction starts leaking.
The "map multiple tables to
On 8/22/06, JP <[EMAIL PROTECTED]> wrote:
> I still think there is some kind of definitional crosstalk here,
> because I don't see what's less simple or more tightly coupled about:
No, the difference isn't in definition; there are pooling utilities
which do "multiple connections to multiple datab
On 8/22/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Is this still waiting on django.db.models refactoring? The wiki page
> hasn't been updated in a while.
The wiki page probably isn't the most reliable guide; I haven't looked
at it, but I'd guess that it's been superseded by discussions on this
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
> plan in Trac?
I think Brant's rocking the sexiness; the concept of validation
behaving as a try/except block feels nice to me. And bidding good-bye
to 'if errors', FormW
On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> The problem is that to make it usefull to the user (read: api-user /
> developer), you have to put the model save in a try / except block so
> that if there is a validation error, it can raise the form.
> Otherwise, the user will have to pro
On 8/24/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> No, watch for the difference between a ValidationError being raised
> and a Form exception being raised. In the ValidationError case, it
> must be saved and returned with the other validation errors in the
> given step (1. conversion; 2. fo
On 8/24/06, JP <[EMAIL PROTECTED]> wrote:
> I like James Bennetts's example a lot, but I'd like it more if the form
> class were ModelForm, descending from a more general Form class that
> would look much like the base Manipulator class of today.
I think you're confusing me with someone else...
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I think the piece on which I agree with JP is that a _form_ serving as
> an exception is counter-intuitive. I would prefer an exception to be an
> error dict that is then used to display them.
I'm not so sure about that. The form itself was t
On 8/26/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
> Yes, a lot of things would be better handled at the database level,
> e.g., inheritance, views, more advanced validation, but it would break
> database independence.
Inheritance makes sense in the ORM, because we want to be able to map
inheri
Someone in IRC tonight was running into the problem described in
ticket #343 tonight, and after a quick test I can verify it's still
happening in trunk. I'm blacklisted in Trac right now (Tom's looking
into it), so I'll post some thoughts here.
The root of the problem is that OneToOneField inheri
On 8/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I hadn't seen this mentioned on the lists.
There are a couple of Rails admin systems floating around; one even
(literally) copies the Django admin look and feel.
--
"May the forces of evil become confused on the way to your house."
-- Geor
On 8/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> all of these types of things should get as much info as possible out
> of the database/models that exist
> having to retype the relationships sounds yuko to me.
DHH has a thing about that; he doesn't think information about admin
representation
Personally, I like the form exception thing, but if enough people
think it's un-Pythonic or too expensive to use an exception for it,
then I can get behind that.
I like a lot of the stuff in Joseph's proposal, especially the method
of handling read-only fields (that would solve a lot of common
pr
On 8/30/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> My only quibble is the recommendation in the docs to call
> ``ping_google()`` from the ``save()`` method. I think the idea of
> setting off a HTTP request from within a ``save()`` method isn't such
> a grand idea; network latency could ca
On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The committer russelm said: Template variable evalution should follow Python
> norms.
As I understand it, the distinction is between the string 'False' and
the boolean False.
In other words, if you pop open a Python shell and do this:
On 9/5/06, limodou <[EMAIL PROTECTED]> wrote:
> So I think the later is more comfortable. But there is no automaticly
> authenticate in create_user, so for now, I must write like the former.
As I said in the ticket (that was me, btw, not Adrian), I think your
second method of just calling 'login'
On 9/6/06, GinTon <[EMAIL PROTECTED]> wrote:
> 1) Has more preference the contributors of Google summer code that the
> one independents?
For the students who did SoC projects, they of course can choose any
license they want. But if they want their projects to be merged into
Django proper, they n
On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote:
> Martin's version is indeed faster, but has a 'gotcha' in that it precludes
> passing a keyword arguments named 'fct' to a curried function...
If you look at the changeset checked in by Adrian[1], it's slightly
different than Martin's origina
On 9/9/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Thinking a little higher level, it feels like we should be avoiding the idea
> of a 'default' manager as much as possible. We let people define multiple
> managers, but we fall back to the default far too often.
Agreed; there are a coupl
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> 1. why are these personal values (first name, last name, email) there
> in the first place? did I miss something?
The User model is not meant to be an exact match for the needs of 100%
of all possible authentication use cases; instead it's meant t
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> in my view, anything that´s not needed for user-authentication
> belongs to a user-profile. for me (and I may be wrong here) a user-
> profile is for personal information (like first name, last name,
> address and what have you).
As I see it, pari
On 9/11/06, Joe <[EMAIL PROTECTED]> wrote:
> Any progress on this? We should make a timeline.
Well, it's hard to have a timeline for this sort of thing. What we
need right now is *not* developer time, what we need is *user* time.
In other words, we need people to:
1. Check out the SoC branches
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
> There's a high barrier to entry when I have to deconstruct the test
> architecture before I can contribute a simple patch.
http://www.djangoproject.com/documentation/testing/
--
"May the forces of evil become confused on the way to your house."
On 9/13/06, Hawkeye <[EMAIL PROTECTED]> wrote:
> It doesn't explain how the django-developers have constructed their
> test suites, and how one can build upon them.
Django's own tests use the same system (mostly they're doctests).
--
"May the forces of evil become confused on the way to your ho
101 - 200 of 1014 matches
Mail list logo
