On 10/2/07, Xan <[EMAIL PROTECTED]> wrote:
> I know that this behaviour is documented, but is it a bug so?. The
> strange behaviour of admin, even altough it's documented, is strange.
> Why you don't consider it a bug? Is there a ticket of that? Do you
> plan to change this (strange) behaviour in
On 10/3/07, Florian Lindner <[EMAIL PROTECTED]> wrote:
> Oh sorry, I didn't really consider this a discussion.
There's nothing to discuss, really. Porting Django to Python 3 isn't
even a theoretical possibility until Python 3 is released in a
finalized form and all of the libraries we depend on (
On 10/4/07, Peter Nixon <[EMAIL PROTECTED]> wrote:
> I tried to open the following ticket but it thinks my IP is a spammer, so I
> am sending to the list:
If you create an account in Trac, it won't apply spam filtering to you.
--
"Bureaucrat Conrad, you are technically correct -- the best kind
On 10/4/07, Mikkel Høgh <[EMAIL PROTECTED]> wrote:
> The reason I have not reopened that particular ticket is that I don't
> know
> how you do things in the Django community. I assume that the one that
> closed the ticket was Jacob Kaplan-Moss, and since I respect his
> opinion,
> I considered it
On 10/5/07, Milad <[EMAIL PROTECTED]> wrote:
> I am interested in translating to persian
> Could you clue me how can I send files for you and accept process
> and ... ?
http://www.djangoproject.com/documentation/contributing/#submitting-and-maintaining-translations
--
"Bureaucrat Conrad, you ar
On 10/17/07, Dan Watson <[EMAIL PROTECTED]> wrote:
> I was wondering what people thought of adding a .exists() method to
> querysets that would take another QuerySet, and add a "WHERE EXISTS
> (SELECT ...)" to the original query. It would require that the passed-
> in QuerySet be joinable with the
On 10/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I'd like to improve the quality of Django's documentation.
> I'm sure there will be many opinions on what "improvement" would mean.
I'm also interested, though I keep running out of hours in the day to
work on it :)
> I'd like to solic
On 10/19/07, wnielson <[EMAIL PROTECTED]> wrote:
> I must have passed over that one a hundred times without seeing it
> once...
At some point I'd like to see the get_absolute_url() method on the
User model rewritten to use the permalink() decorator, which would do
away with the need to override o
On 10/19/07, wnielson <[EMAIL PROTECTED]> wrote:
> I needed the ability to set a custom url for the User model, so I
> modified the User model's `get_absolute_url` to allow endusers to
> define an attribute, `AUTH_USER_URL`, in their settings file. `/users/
> /` is still the default, but can simp
On 10/28/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> [Rant]
I'm inclined to forward this upstream to Python, which steadfastly
maintains separate "datetime" and "time" modules.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~
On 10/29/07, Ed Summers <[EMAIL PROTECTED]> wrote:
> Does anyone know if there are any plans to merge the multi-db branch
> [1]. I see in ticket #1142 that things are kind of quiet on the
> development side. Did this come up at all during the big spring of
> 14-Sep-2007?
You probably want to star
On 10/30/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> It's always bugged me a little that choice lookups are based on the raw value.
>
> Example for discussion:
> CHOICES = (
>(1, 'parrot'),
>(2, 'argument'),
> )
>
> class Profile(models.Model):
> user = FK(User)
> favorite_skit =
On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> James, I think you've managed to hit (what I'd consider) the perfect
> stride there. You have to import Entry anyway, so by making your
> constants class attributes, you avoid the extra import requirement.
It's not quite an enum, but it's clo
On Nov 6, 2007 4:17 PM, Charles <[EMAIL PROTECTED]> wrote:
> I've installed Django v.0.96 on an Ubuntu Linux 7.10 system and am
> going through the tutorial available at the Django site. The latest
> error popped up when I tried to run the admin app. The current error
> is:
>
> ImproperlyConfigure
If/when we ever do finally sit down and implement an auto-escaping
proposal, I'd like to suggest we also just go ahead and turn on the
CSRF middleware by default, because apparently the fact that it isn't
enabled by default is leading people to scream about security
vulnerabilities in Django[1], w
On Nov 7, 2007 10:26 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> ModelForm would be a declarative class that requires, at minimum, a
> model attribute. Other attributes would include:
>
> - formfield_callback (a function that takes a db field and **kwargs
> and returns a form field or None)
On Nov 7, 2007 7:08 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> Which means that this basically boils down to an annoyance attack,
> changing a user's password without their knowledge. But that's already
> exposed to anyone who can guess the user's email address
On Nov 7, 2007 5:22 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I have quite a different view about the severity of this. Out of the
> box, Django has a CSRF vulnerability if you use admin. I'm not inclined
> to dismiss this as a nothing event that you can work around by somehow
> magicall
On 11/12/07, arungandhis <[EMAIL PROTECTED]> wrote:
> I have a scenario where a user has logged in the application and he is
> navigating through the application.
> on every navigation i want to check whether the user has a valid
> session.
> do i need to write the code to check for the session in
On 11/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Perhaps Model.save(raw=False) should become Model.save(raw=False,
> fire_signals=True), leaving it up to the overrider to decide the
> policy?
Personally, I'm comfortable with documenting the fact that if
Model.save() is never called, the pre
On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> How about introducing pre_save and/or post_save methods. The signal firing
> happens in pre_save and post_save. You can override whatever you want -
> pre_save, save, or post_save depending on your needs. This would also allow
> you to disab
On 11/17/07, ElegSub <[EMAIL PROTECTED]> wrote:
> We will disagree about the accuracy of that statement but your
> response is by far the most clear and succinct response to this
> question yet. Thank you.
The problem is that people pop up every couple weeks and ask precisely
the sort of thing yo
On 11/19/07, Greg_IAP <[EMAIL PROTECTED]> wrote:
> Does someone could explain to me how to make it work?
> several examples on the net show that it doesn't...
You're going to need to ask a more specific question here; "I read
somewhere that X didn't work" is pretty useless as questions go.
Provid
On Nov 21, 2007 6:50 AM, onno <[EMAIL PROTECTED]> wrote:
> Why, did you developers not decide to include a automatic "class
> required" value for label and input fields.
Have you considered searching the ticket tracker for the open tickets
on this issue and proposals for the best way to restore t
On 11/22/07, Goutham DL <[EMAIL PROTECTED]> wrote:
> Iam new to this community. I would like to know more about the django
> ORM(i.e its internal workings). Can someone provide some good links
> for this?
http://code.djangoproject.com/wiki/DevModelCreation
--
"Bureaucrat Conrad, you are technic
On 11/25/07, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote:
> I'm requesting someone please fix the code to the sessions module to
> make Django secure.
I'm going to play devil's advocate here, not out of any personal
malice, but simply because it's important to have *someone* do it in a
case li
On 11/30/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.
Sounds great to me :)
> What am I forgetting?
I'd add model subclassing to the list, if only because it feels as if
the API has been mostly agreed upo
On 11/30/07, firedancer <[EMAIL PROTECTED]> wrote:
> i'm new to using django ,
> i would like to proceed with it ,
>
> your help will be more then appreciated
Your best hope is to thoroughly read the official Django tutorial,
which explains the need to either use manage.py or properly state
which
On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Frankly, I have found the slicing syntax hard to understand and
> error-prone myself.
I guess I'm curious as to what's difficult or error-prone about it;
I've never run into a problem where slicing was the cuplrit, and it
feels like a more
On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Frankly, I have found the slicing syntax hard to understand and
> error-prone myself. I think one of the reasons it seems magic is that
> it's one of the *rare* cases in which we use a Python
> "magic-syntax-ism" (like operator overloading,
On 12/3/07, Mike Scott <[EMAIL PROTECTED]> wrote:
> James, I'm think what I'm getting at more is not the fact that its
> "magical", maybe that is the wrong choice of word. But my opinion is more of
> the fact that it doesn't conform to the rest of the django database
> commands.
I suppose it depe
On 11/30/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> It's probably too big a feature to start talking about now, but I'd be
> really interested in seeing Django applications (in particular the
> URLconf part) unified with the concept of a Django view, so a Django
> application is a callable th
On 12/3/07, Simon Willison <[EMAIL PROTECTED]> wrote:
> I'd like to see the distance between a Django application (or a
> Django view) and WSGI as small as possible. Imagine if you could drop
> a Django view in to any WSGI container just by applying a WSGI-to-
> Django-view wrapper of some sort. O
On 12/3/07, David Cramer <[EMAIL PROTECTED]> wrote:
> For the most part I'm just doing if request.POST to validate.
The request.method attribute exists precisely for this purpose, so
that you can find out what the HTTP request method was ;)
--
"Bureaucrat Conrad, you are technically correct --
On 12/3/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
The only objection I'd have is that it would enable naive code to
screw up by just looking a
On 12/4/07, Travis Terry <[EMAIL PROTECTED]> wrote:
> Previous proposals to address this issue involved adding either a thread
> lock or a DB table lock around the get_or_create() call. Both of these
> are unacceptable. The thread lock does nothing to prevent the problem
> when using multiple fr
On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> I don't have a suggestion for a replacement, and I don't think it needs to
> be on the 1.0 list (since it can be added without breaking backward
> compatibility), but I think it would be a big plus.
While I actually like the power and flexi
On 12/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have updated the ticket. I resolved my issue but uncovered more. I'm
> guessing no one wants to work on the existing admin interface with
> newforms-admin nearing...?
There was already another ticket open for this issue, and a note that
I'd like to propose some refactoring of ModelForm to bring it into
line with the standard conventions of other newforms forms. Right now
there are two main issues:
1. A standard django.newforms.Form accepts POST data as its first
positional argument, while a ModelForm expects an instance of the
m
Since code speaks louder than words, I've opened ticket 6162[1] and
attached a patch which:
1. Makes "instance" the *last* argument to ModelForm.__init__().
2. Has ModelForm fall back to creating an instance of _meta.model if
the "instance" argument isn't supplied.
Updated tests and docs are als
On Dec 8, 2007 11:29 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> So, I'm going to pretend you didn't say anything about rearranging
> positional arguments because a) it doesn't work, and b) your patch
> doesn't do that.
It does, it just makes 'instance' the last positional argument.
Whethe
On Dec 8, 2007 11:51 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> That's exactly what I'd imagined. Your example can be solved right now
> by the following:
>
> class LatLongForm(ModelForm):
> class Meta:
> fields = ('
OK, so after chatting a bit with Joseph on IRC I'm working on revising
my original patch. The changes it makes still need some discussion, so
I'll outline them here.
1. The "instance" argument to ModelForm.__init__() essentially becomes
a keyword argument defaulting to None, and moves out of the
I've just attached a new patch which (hopefully) makes everything work
in an acceptable way:
1. The argument ordering is still fixed, and you'll still want to pass
"instance" as a kwarg in most cases.
2. A ModelForm with neither model nor instance is an error.
3. A ModelForm which works on any of
On 12/10/07, oggie rob <[EMAIL PROTECTED]> wrote:
> Shouldn't this operation occur in the newforms framework, since the
> distrust comes from user-entered data, and the decisions on what
> should be trusted and what shouldn't come from the form developer?
No, no, no, a thousand times no.
In shor
I'm still curious why it is, that if people want to define models
without having Django create tables, those people don't just avoid
running 'manage.py syncdb'.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~
While playing around a bit with newforms-admin, I noticed that it's
ever-so-close to being able to handle one cool use case which came up
during the design discussion at PyCon: running django.contrib.admin
without django.contrib.auth.
The implemention of has_permission() on AdminSite, and
has_(ad
On Dec 17, 2007 1:34 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm either confused or scared. Presumably the admin application still
> relies on authentication, right? Without making me rustle through all
> the code, can you explain how it is enforcing access restrictions
> without the a
On Dec 17, 2007 3:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tell me if I'm crazy here, but what if LogEntry objects were created
> upon emission of some signal? That way, other apps could hook in and
> log their own actions as well, along with removing the admin's
> dependency on auth
On Dec 17, 2007 5:36 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Yes, right. But here is patch from 8 months ago:
> http://code.djangoproject.com/attachment/ticket/3275/fix_depth_bug.diff
> and why it isn't in branch head?
Perhaps you didn't read the information on that ticket, which answe
On Dec 18, 2007 2:12 AM, David Danier <[EMAIL PROTECTED]> wrote:
> Correct me if I'm wrong, but doesn't this miss the big parts when
> writing your own auth-application. After adding this two methods the
> tables for LogEntry and Message still exist in the database, but are
> unusable. If you want
On Dec 19, 2007 6:47 AM, David Danier <[EMAIL PROTECTED]> wrote:
> True, but having to duplicate every app in django.contrib I want to use
> (and which uses django.contrib.auth.models.User) only because the
> ForeignKey is wrong, that's bad in my opinion. And fixing the admin will
> not really hel
On Dec 19, 2007 4:26 AM, SmileyChris <[EMAIL PROTECTED]> wrote:
> What I find mildly amusing is Malcolm's comment in the ticket [1]
> which is pretty much the opposite of what he's saying now. In his
> defence, he did say he would have to think about it for a bit
> longer ;)
What strikes me about
Guys, this is really degenerating into a bikeshed issue. Let it rest
for a while, OK? Endless "me too" comments don't add anything useful
to the discussion, and there are larger and more important things to
be working on right now.
And if anybody feels the need to post a snarky comment about
perf
On Dec 23, 2007 12:13 AM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> I clicked on the login link in track (in case it brought me to a log
> in/create account page) That's not how trac works though. I ended up at
> this link:
> http://code.djangoproject.com/wiki/TracGuide
At the moment, AFAIK it's
On Dec 26, 2007 5:15 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
> However, with svn, you can inline the login_required right in urls.py;
Actually that's available in 0.96 as well. And it's far better and
more flexible than trying to hard-wire a 'login_required' argument
into every generic view.
On Dec 27, 2007 9:22 AM, kevinski <[EMAIL PROTECTED]> wrote:
> This worked great, however shouldn't there be some uniformity in how
> the Login_Required argument is applied in all the generic views? This
> was not the most obvious solution, and I did not see it anywhere in
> the documentation.
Ri
On Jan 2, 2008 10:55 AM, shabda.raaj <[EMAIL PROTECTED]> wrote:
> Built in views like django.contrib.auth.views.password_change still
> use the oldforms library. Is this due to some design decision or is it
> this way because nobody has yet converted them to newforms?
It's because the transition
On Jan 9, 2008 9:11 AM, rick <[EMAIL PROTECTED]> wrote:
> Any chance any of the developers of this db backend are on this list ?
Please don't send messages like this to the list; this list is for
discussion of developing Django itself.
Also, that project is hosted at Google Code and so has its o
On Jan 9, 2008 6:40 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sorry, disregard... got the ticket in here
> http://code.djangoproject.com/ticket/6351
Also, note that per the documentation on contributing to Django[1],
the preferred process is to create an account in Trac (or, at least,
t
On Jan 12, 2008 5:25 PM, Roberto Saccon <[EMAIL PROTECTED]> wrote:
> but the following, in my opinion better version, is not supported:
>
> 2) {{ foo="hello world" }} or {{ bar=77 }}
>
This is a deliberate design decision; the Django template system is
meant to implement only the level of
On 1/12/08, Wanrong Lin <[EMAIL PROTECTED]> wrote:
> I have a data model case that I think probably is quite common to other
> people too, and I did not find a way to do it with current Django, so I
> wonder whether the developers can take a look of it.
A search of the archive of this list will r
On Jan 12, 2008 8:31 AM, shabda.raaj <[EMAIL PROTECTED]> wrote:
> When we run django-admin.py, it generates SECRET_KEY and writes that
> value. Now if we create some apps and these apps are downloaded and
> used as-is by the users they end up sharing the SECRET_KEY.
> That setting recommends that
While looking at #5614[1] and thinking about fixing up the patch so it
could be committed, it occurred to me that, with the infrastructure we
now have for custom management commands, there's no real need for
contrib/auth/create_superuser.py to exist anymore.
So what I'd *like* to do is:
1. Add a
On Jan 27, 2008 5:43 AM, tawny <[EMAIL PROTECTED]> wrote:
> tried last night and again this morning to do an svn checkout which
> fails with this response
>
> Atrunk/django/conf/locale/hr/LC_MESSAGES
> Atrunk/django/conf/locale/hr/LC_MESSAGES/django.po
> Atrunk/django/conf/locale/hr/LC
On Feb 7, 2008 8:29 AM, MikeH <[EMAIL PROTECTED]> wrote:
> So I modified the admin app to let you override the edit inline templates in
> your own applications,
> using the admin/app_name/model_name/edit_inline_(stacked|tabular).html
> convention that the other admin templates use.
>
> The diff i
On Feb 18, 2008 5:06 AM, Jiri Barton <[EMAIL PROTECTED]> wrote:
> The infamous commit #7126 seems to obsolete generic relations -- to
> me.
Not by a long shot.
To take your example, you'd need to go back and rewrite every single
model you'd like to use tags with to inherit from the appropriate b
Please note that this list is for discussion of the development of
Django. Things which do not involve discussion of the development of
Django do not belong here.
This concludes your friendly reminder.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~
On Tue, Mar 4, 2008 at 11:23 AM, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> Exactly. This seemed like such a basic concept (select from array based on
> variable value) that I was sure that it's hidden in django somewhere. I
> can't be the first one to need this?
Yes and no. The thing is that a Py
Ticket #6705 [1] proposes that 'form.errors' be changed to somehow
provide a "prettier" display not based on the underlying field name
(which is currently used as the key in the errors dictionary).
The person who opened this ticket contends that it is a common issue,
and that there is no existing
On Tue, Mar 4, 2008 at 9:22 PM, Dj Gilcrease <[EMAIL PROTECTED]> wrote:
> he cant do something like http://dpaste.com/38006/ ?
The desired case is for {{ form.errors }} to somehow do something
similar, but automatically.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of c
On Tue, Mar 4, 2008 at 1:37 PM, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> Is there a sound technical reason not to add a filter, ie. is there a
> performance penalty involved? Or is there a fundemental problem with the
> design that I had in the first posting? I'm going to be adding this
> functio
On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> Would proposing a complete replacement be a tad too controversial for a GSoC
> project?
Yes. It also wouldn't succeed as a project, because it's the Google
*Summer* of Code, not the Google Several Years of Code.
--
"B
On Mon, Mar 24, 2008 at 11:15 PM, Alex P <[EMAIL PROTECTED]> wrote:
> 1. The original message was in brief: there is a growing interest in
> the Python community for DB2 support, and we (developers behind IBM_DB
> driver, DB-API wrapper and SQLAlchemy adapter) are interested to help
> in the D
On Tue, Mar 25, 2008 at 4:59 AM, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> Unfortunately, django.db.backends.dummy falls below the bar for minimal API
> documentation. While it may have the names of the entry points, they are
> all defined as complain(*args, **kwargs), and they have no docstri
On Wed, Mar 26, 2008 at 7:03 PM, Rodrigo Bernardo Pimentel
<[EMAIL PROTECTED]> wrote:
> Martin mentioned that he would be willing to co-mentor me for GSoC along
> with a Django developer, with either one being the "official" mentor.
>
> So I'd like to know what you think about this as a GSoC pr
On Thu, Mar 27, 2008 at 12:56 AM, Graham Dumpleton
<[EMAIL PROTECTED]> wrote:
> Actually, I already have a copy of mod_wsgi mostly working on Python
> 3.0, just sorting out areas where now need to handle both unicode and
> bytes, where before only used to have to deal with bytes (old string
>
On Thu, Mar 27, 2008 at 2:30 PM, Rodrigo Bernardo Pimentel
<[EMAIL PROTECTED]> wrote:
> Besides, people are already experimenting with porting their code to py3k,
> so I'm getting the feeling it won't take so long for libraries to get
> ported. Requests from Django developers who are already pl
On Thu, Mar 27, 2008 at 3:56 PM, Martin v. Löwis
<[EMAIL PROTECTED]> wrote:
> Please see my recent report: 0 years, 0 months, 0 days, 0 seconds.
> You can (probably) support Python 2.x and Python 3.x out of a single
> source tree.
I hope you won't take it the wrong way when I say I have an ext
On Fri, Mar 28, 2008 at 5:54 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> schema-evolution is separable from applications -- it's utility, and
> applications codes are still compatible with each other, but different
> querysets features as 3rd-party libraries could make project code
> incompa
Do not use this list for questions about how to use Django.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" grou
On Sun, Mar 30, 2008 at 3:35 PM, onno <[EMAIL PROTECTED]> wrote:
> Would some developer consider this problem for custom made
> applications that don't want to use default permissions but there own
> custom permissions without the default permissions getting in the way.
> The permmision module
On Mon, Mar 31, 2008 at 6:52 AM, Ivan Illarionov
<[EMAIL PROTECTED]> wrote:
> Hey, I've just found that ticket #6789 was merged into trunk while my
> ticket #6654 that was filed a month earlier and does the same thing
> was ignored.
The one that was checked in appears to have had its patch att
On Mon, Mar 31, 2008 at 7:25 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> Technology helps in some places, but there's no replacement
> for a good editor. And I'm *not* talking about Emacs.
The next release will have 'M-x copyeditor' for that, actually...
--
"Bureaucrat Conrad, you are
On Tue, Apr 1, 2008 at 2:31 AM, jurian <[EMAIL PROTECTED]> wrote:
> All I need to know is if this is some kind of fall-back till full-
> blown model inheritance is implemented, or if this is just a fluke.
It's a fluke. More information can be obtained from a Google search
for "Django model inhe
On Wed, Apr 2, 2008 at 10:47 AM, AmanKow <[EMAIL PROTECTED]> wrote:
> Will the api and internals references be generated (at least in part)
> via doc string extraction? That's a big plus to me.
I most sincerely hope not; unless you're like me and write short-form
novels in your docstrings, the
On Wed, Apr 2, 2008 at 7:06 PM, msaelices <[EMAIL PROTECTED]> wrote:
> Now, what do you see? You first think again in a form with two fields,
> however maybe is a form with five fields. What is happening? You
> explicity define two fields, and the real action is a _redefinition_
> of two field
On Mon, Apr 7, 2008 at 7:52 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> To answer my own question, it turns out dynamically constructing a
> class is really easy if you take advantage of closures:
Yup. I've got a generic user-profile-editing app which uses that exact
trick to get a form for
On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> It was discussed previously that making URL matching easier by not
> having to understand regular expressions would be a nice goal, and
> perhaps a nice 1.0 goal...
Two things:
1. If Django were going to support an altern
On Tue, Apr 8, 2008 at 4:10 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Maybe the documentation refactoring could include an Appendix:
> "Introduction to REGEX" and "The regular expressions you'll find
> everyday" or something like that.
>
> With this, newcomers would have an introduct
On Thu, Apr 10, 2008 at 12:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> mymodel.choicefield.display()
So we're going to stuff extra methods onto, say, an 'int' object?
Because that's what the descriptor should return, and having it
magically sprout methods like this would be more than a litt
On Fri, Apr 11, 2008 at 3:29 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
> (Replying to myself.) Looking at the code I see they're just urlconf
> module globals. I assume they only take effect in ROOT_URLCONF?
Documentation here:
http://www.djangoproject.com/documentation/url_dispatch/#handler
On Sun, Apr 13, 2008 at 6:05 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> I was wondering about the reason that middleware classes were used instead
> of decorators to implement middleware functionality.
There are two cases, each with drawbacks:
1. Whatever system is available to provide addit
On Mon, Apr 14, 2008 at 3:30 AM, James Bennett <[EMAIL PROTECTED]> wrote:
> the useful tricks that a real middleware can do -- for example, you
> can't tweak request.urlconf to change URL resolution, because by the
> time a decorated view comes into play the URL resolut
On Fri, Apr 18, 2008 at 11:41 AM, Andrew D. Ball <[EMAIL PROTECTED]> wrote:
> Look at what happens when I ask Django what version number it has (this is
> from release 0.96.1):
Honestly, for future releases I'd personally like to stick to a pattern of
(major, minor, modifier)
So if we release
And because lately we've been doing various specification-type things,
I'd like to propose (with release manager hat firmly planted on my
head) that going forward we do things in the following fashion.
Format of ``django.VERSION``
``django.VERSION`` is a 3-tuple, of
On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> That said, I think I agree with Steve's idea of ripping of
> sys.version_info: we've already stolen so much process from Python why
> not add to this list?
The main reason I didn't do that is simply that Python goe
On Sat, Apr 19, 2008 at 2:37 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I've noticed that a LOT of people get bitten by the problem where
> every SQL statement is logged if DEBUG=True, resulting in huge memory
> consumption after a while. This problem seems particularly common for
> impor
On Sat, Apr 19, 2008 at 10:17 AM, ydjango <[EMAIL PROTECTED]> wrote:
> Is there a reason you cannot call it just 1.0
So would you prefer to have a beta-quality product whose developers
lie and call it 1.0?
The next version of Django to be released will be 1.0. It will most
likely be preceded by
On Wed, Apr 23, 2008 at 11:16 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Now that queryset-refactor has implemented model inheritance (and will
> soon be in trunk), will the recommended way to tie in new columns to
> contrib.auth.models.User change? For example, if we want to add in
> profil
901 - 1000 of 1014 matches
Mail list logo
