On Sun, 2007-09-09 at 23:25 -0500, Adrian Holovaty wrote:
> On 9/9/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I see the problem. The reloader uses sys.argv and grabs the last command
> > line directly. By the time it gets to runserver.Command.handle, the
> > command line has been munged a lit
On 9/9/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> So if we have several confirmations of breakage, shouldn't it be
> rolled back?
Nah, no need to roll this one back, unless it takes forever to figure
out. The changeset has too many files, and the breakage isn't
horrible.
Adrian
--
Adrian Hol
On 9/9/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I see the problem. The reloader uses sys.argv and grabs the last command
> line directly. By the time it gets to runserver.Command.handle, the
> command line has been munged a little.
That doesn't make any sense, though. Which part of the code
On Sep 10, 2:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Hmm, I confirm I get the same error on OS X -- it happens after the
> server is reloaded. How strange...
So if we have several confirmations of breakage, shouldn't it be
rolled back?
--~--~-~--~~~---~
Marty Alchin wrote:
> So, just so I'm clear, is this for everybody, or just the core
> developers? For instance, I'm actively maintaining the new filestorage
> mechanism for the time being, so should I accept that as my own?
Everybody and yes.
Gary
--~--~-~--~~~---~-
On 9/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> So, just so I'm clear, is this for everybody, or just the core
> developers? For instance, I'm actively maintaining the new filestorage
> mechanism for the time being, so should I accept that as my own?
Everybody -- please do claim that ticket!
On Sun, 2007-09-09 at 21:55 -0500, Adrian Holovaty wrote:
> On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > I'm seeing breakage too: I haven't tested it that extensively, but I'm
> > getting the following pair of tracebacks consistently on Windows on
> > the first reload of the serve
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm seeing breakage too: I haven't tested it that extensively, but I'm
> getting the following pair of tracebacks consistently on Windows on
> the first reload of the server:
Hmm, I confirm I get the same error on OS X -- it happens afte
On 9/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 23:41 +, SmileyChris wrote:
> > On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > > On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > >
> > > > I think my refactoring of django.core.managemen
Okay, I guess I'm not much on doing fun stuff with RSS, but I went
ahead and set up a Yahoo Pipe[1] to keep track of the various blogs
that are currently (or will be) dealing with the topic of Django on
Jython. If anybody else is writing on the subject, let me know and
I'll add you to it.
-Gul
[
On 9/6/07, David Elias <[EMAIL PROTECTED]> wrote:
> Some backends provide some type_cast functions that you can attach to
> some data types, on a quick search for zxJDBC I found in the home page
> "Datatype mapping callbacks through DataHandler", don't know if this
> has the same functionality ju
On 9/9/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> FYI, in order to "accept" a ticket you need an account and need to be
> logged in. To create an account, go to
> http://djangoproject.com/accounts/register/, and then log into trac
> (using the "login" link at the top right).
So, just so I
On Sun, 2007-09-09 at 23:41 +, SmileyChris wrote:
> On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > > I think my refactoring of django.core.management to let each command
> > > register its own options is complete
On 9/8/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 9/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Any serious opposition?
>
> Not at all -- this sounds perfectly sensible, and a good improvement.
Committed in [6080]. I don't think anything in there makes Russell's
suggestion
On 9/9/07, pm13 <[EMAIL PROTECTED]> wrote:
>
> I am sorry. You are missing nothing - I don't use python for long time
> and I haven't realize yet it is possible to override attribute by
> property (now I see that it is logical.)
It's ok. I just felt I was misunderstanding your problem. :)
> But
> > I created example of the first solution:
> >http://code.djangoproject.com/ticket/5372
>
> The patch you attached in that ticket looks like it will solve your
> problem, and in fact, you can just subclass TabularInline or
> StackedInline, override the formfield_for_dbfield on you subclass, and
Hi,
Submit your web site for FREE and be exposed to potentially TENS of
THOUSANDS of new and unique visitors!!
Click for more information ;
http://www.hits2u.com/?428901
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've committed it in [6075].
It would
On Sun, 2007-09-09 at 17:16 -0500, Adrian Holovaty wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've committed it in [6075]. I left a few commen
On 9/9/07, pm13 <[EMAIL PROTECTED]> wrote:
>
> I think that there was call of function "formset_for_model" in each
> request (ModelAdmin.get_inline_formsets -> inline_formset ->
> formset_for_model). But now this method is called from
> ModelAdmin.__init__ (ModelAdmin.__init__ -> InlineModelAdmin
On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I think my refactoring of django.core.management to let each command
> register its own options is complete.
Great stuff, Todd. I've committed it in [6075]. I left a few comments
at http://code.djangoproject.com/ticket/5369 about the main chang
I have a problem with this changeset. I have some inlines with foreign
keys. By default there is one SQL query for each row - result is not
cached. So I used this code in formfield_for_dbfield:
if isinstance(db_field, models.ForeignKey):
kwargs['cache_choices'] = True
The argument cache_cho
Howdy --
Thanks, Adrian -- this needed to be done!
FYI, in order to "accept" a ticket you need an account and need to be
logged in. To create an account, go to
http://djangoproject.com/accounts/register/, and then log into trac
(using the "login" link at the top right).
Jacob
--~--~-~-
While not exactly what you're looking at, something I had considered
some time ago was putting together a set of wiki articles that are
geared toward more of a quick-reference documentation. I put together
articles for HttpRequest[1] and HttpRespone[2], but never got any
further than that.
As you
In an effort to get our ticket system cleaned up before Friday's
sprint, I've done some housekeeping regarding the "Assigned to" field.
Until now, that field has effectively been ignored because every
ticket is automatically assigned to either me or Jacob as soon as it's
submitted. It's misleading
Tomas Kopecek napsal(a):
> Honza Král napsal(a):
>> On 9/9/07, Tomas Kopecek <[EMAIL PROTECTED]> wrote:
>>> Honza Kr�l napsal(a):
can you replicate this with DEBUG=False in your settings?
without DEBUG turned on, no queries will be saved. I very much doubt
that all these sites
Honza Král napsal(a):
> can you replicate this with DEBUG=False in your settings?
>
> without DEBUG turned on, no queries will be saved. I very much doubt
> that all these sites built on Django are either leaking memory or not
> using large quantities of objects like this one here.
I've got some
Honza Král napsal(a):
> On 9/9/07, Tomas Kopecek <[EMAIL PROTECTED]> wrote:
>> Honza Kr�l napsal(a):
>>> can you replicate this with DEBUG=False in your settings?
>>>
>>> without DEBUG turned on, no queries will be saved. I very much doubt
>>> that all these sites built on Django are either leakin
On 9/9/07, Tomas Kopecek <[EMAIL PROTECTED]> wrote:
>
> Honza Kr�l napsal(a):
> > can you replicate this with DEBUG=False in your settings?
> >
> > without DEBUG turned on, no queries will be saved. I very much doubt
> > that all these sites built on Django are either leaking memory or not
> > usin
Hi Devs,
One of the things I'm always stuck with when reading the docs is
knowing where to import the described methods or objects from. For
example, just now I'm working on Q objects and just read the
documentation but don't know where they live without having to jump
into the source of where I
On 9/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> If you use the newforms-admin branch and the edit inline
> functionality, you want to read this.
>
> I'm planning on breaking the current syntax for defining inlines in
> the very near future, but I figured I'd warn people and ask for
> com
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> > > No - this has nothing to do with the test framework. It's a set of
> > > helper functions to support wri
Hi Devs,
I just bumped into this and can see both sides so I'm posting here...
I'm working on a project that wants a list view to have configurable
num_per_page for pagination. I set it up to pull from the GET (eg: /
search/category-slug/?per_page=10). What I did was check for the
existence of
On Sun, 2007-09-09 at 10:56 -0500, Joseph Kocherhans wrote:
[...]
> I suppose I could make the syntax backwards-compatible by naming the
> factory functions the same as the existing classes, but I think it
> would make things more confusing.
I think you're more across the subtleties of this featu
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > If you use the newforms-admin branch and the edit inline
> > functionality, you want to read this.
> >
> > I'm planning on breaking the current syntax for defining inlines
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to change the 'fields' attribute on ModelAdmin to
> > 'fieldsets', and use 'fields' for a tuple of field names rather than a
> > list of (fieldset_name, options) t
There will also be a Prague chapter in my company - NetCentrum, we can
provide space, connectivity and perhaps some junk food ;)
Everybody's wellcome, just drop me a line if you are interested along
with some details so that I can prepare enough tables and computers
(if needed)...
Location
NetCe
On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Drawback if most of the times we are not using that feature, each validation
> statement will have to contain a superfluous self. in the beginning. Whereas
> helper functions can all be imported in the name space. Its only minor
> syntactic sug
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> > No - this has nothing to do with the test framework. It's a set of
> > helper functions to support writing clean_XXX methods.
>
> Okay. Then I'm mostly in agreement, excep
Hi,
since your assert-function won't be like assert in python or UnitTests, you mix
semantics nobody knows everywhere else.
Please remember that assert Statements have special meanings depending on
__DEBUG__
http://docs.python.org/ref/assert.html
http://pyunit.sourceforge.net/pyunit.html#TESTC
On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote:
> On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> > [...]
> > > - I'm also inclined to continue the similarities, and make the
> > > assertion functions me
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> [...]
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of yo
On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
> [...]
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of y
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> >
> > If you use the newforms-admin branch and the edit inline
> > functionality, you want to read this.
> >
> > I'm planning on breaking the current syntax for defining inlines i
Malcolm,
That's basically what I hoped to hear :)
I started looking at model validation in the db model and admin
modules, but following the code led me to newforms, which did left me
wondering if something's still missing.
Thanks for the update, I'll stay alert and jump in to test the new
stuf
>
> OK, it is official, there will be a Copenhagen chapter of the sprint.
> Location:
>
Cool, I'll be there (after work).
Niels
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post t
On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote:
[...]
> - I'm also inclined to continue the similarities, and make the
> assertion functions members on BaseForm. This would allow a
> significant simplification of your proposal, as the data locations
> (i.e., self.cleaned_data) can be
On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> I'd like to change the 'fields' attribute on ModelAdmin to
> 'fieldsets', and use 'fields' for a tuple of field names rather than a
> list of (fieldset_name, options) tuples. Only one of those two options
...
> Any serious opposition?
So
On 9/9/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> If you use the newforms-admin branch and the edit inline
> functionality, you want to read this.
>
> I'm planning on breaking the current syntax for defining inlines in
> the very near future, but I figured I'd warn people and ask for
> c
On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Python unittest TestCase objects have a lot of helper functions like
> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1]. If we
> had a similar set of helper functions, possibly with more pythonic names,
> newform validation
50 matches
Mail list logo
