Wouldn't it be handy to add get_form_instance function to ModelAdmin?
Currently there is function get_form, which actually returns
FormClass. This is then getting instantiated on several places.
Sometimes its important to have possibility to add some attribute to a
form / override some field choic
Jyrki Pulliainen wrote:
> Hi,
>
> is there a particular reason why Lighttpd documentation advices user
> to create a separate script (for example, an init script) to create
> the socket with manage.py? Why not let the Lighttpd take care of
> spawning processes as needed?
>
> If no-one is against i
On Tue, Sep 29, 2009 at 3:51 PM, Peter Cicman wrote:
>
> Wouldn't it be handy to add get_form_instance function to ModelAdmin?
> Currently there is function get_form, which actually returns
> FormClass. This is then getting instantiated on several places.
> Sometimes its important to have possibi
Russ,
On 29 Sep 2009, at 03:25, Russell Keith-Magee wrote:
> (1) know about the trick of instantiating an object with the
> unrolled list version of a cursor, and
Any chance you could expand upon this?
--
David Reynolds
da...@reynoldsfamily.org.uk
--~--~-~--~~~---
On Sep 17, 9:25 am, Simon Willison wrote:
> Problems and challenges
> ===
>
> 1. The Python logging module isn't very nicely designed - its Java
> heritage shines through, and things like logging.basicConfig behave in
> unintuitive ways (if you call basicConfig twice the sec
On Sep 17, 10:37 am, Mat Clayton wrote:
> +1 for this, another random thought which doesn't do your long post justice.
> But what are everyone's thoughts about log aggregation, taking logs from X
> app servers and combining them into a single location, something like
> Facebook's Scribe. I assu
On Sep 17, 11:53 am, Ivan Sagalaev wrote:
> Talking about predictable and standard way I want to be sure that we
> don't break existing logging.
>
> I.e. we at Yandex now have many reusable Django apps that don't setup
> loggers themselves but just log things into named loggers and expect
> the
Your re right, i we missed the third option. It is just happening, if
you wanna do something advanced, and pass some variable from admin to
form. I have to say i have to make form instance modifications twice a
month, mostly because of choices/queryset for a field. It is not
always possible to fak
On Sep 29, 2:24 am, SeanOC wrote:
> During the Djangocon sprints I started to work on a patch which would
> add a nicer interface for dealing with raw SQL queries. While there I
> talked to RKM about where it should fit into the ORM API and where in
> the code base should live. I've finally got
On Sep 17, 3:04 pm, Russell Keith-Magee
wrote:
> In the absence of specifics, this makes me a little bit nervous. The
> Python logging interface may be very Java-heavy and complex, but it is
> a thoroughly known quantity, and it houses a lot of features.
See my comment about Java-heavy being F
On Sep 17, 3:04 pm, Russell Keith-Magee
wrote:
> To clarify - I think that documentation is the very least we should
> do. As your comments indicate, there are a lot of things you need to
> do in order to get logging right, so we should at the very least
> provide some documentation on how to d
On Sep 17, 9:41 pm, Simon Willison wrote:
> I should clarify - by "lightweight wrapper" I basically mean a pre-
> configured log setup and a standard place to import the logger from -
There's no "the logger". Each module should have its own logger, this
allows you to control the verbosity of l
On Tue, Sep 29, 2009 at 4:27 PM, David Reynolds
wrote:
>
> Russ,
>
> On 29 Sep 2009, at 03:25, Russell Keith-Magee wrote:
>
>> (1) know about the trick of instantiating an object with the
>> unrolled list version of a cursor, and
>
>
> Any chance you could expand upon this?
Sure. Assume a simpl
Maxi,
I do have a few bugfixes for the firebird-backend. How can we get in
touch?
Regards,
Thomas
On Sep 28, 11:26 pm, maxi wrote:
> Hi,
> I'm working on implementation of firebird backend for django [1]
> I've an issue related of icontains filter option. Firebird uses
> CONTAINING sql claus
On Tue, Sep 29, 2009 at 5:09 PM, Vinay Sajip wrote:
>
> On Sep 17, 3:04 pm, Russell Keith-Magee
> wrote:
>> In the absence of specifics, this makes me a little bit nervous. The
>> Python logging interface may be very Java-heavy and complex, but it is
>> a thoroughly known quantity, and it houses
On Tue, Sep 29, 2009 at 4:36 AM, Vinay Sajip wrote:
>
>
>
> On Sep 17, 9:25 am, Simon Willison wrote:
>> Problems and challenges
>> ===
>>
>> 1. The Python logging module isn't very nicely designed - its Java
>> heritage shines through, and things like logging.basicConfig beh
On Tue, Sep 29, 2009 at 9:00 PM, Waylan Limberg wrote:
>
> On Tue, Sep 29, 2009 at 4:36 AM, Vinay Sajip wrote:
>>
>>
>>
>> On Sep 17, 9:25 am, Simon Willison wrote:
>>> Problems and challenges
>>> ===
>>>
>>> 1. The Python logging module isn't very nicely designed - its Java
Vinay Sajip wrote:
> Actually you don't need much in settings.py, and Django doesn't need
> to grow any code of its own to "wrap" logging. You can either
> configure logging programmatically (for which I use basicConfig, in
> simple setups) or using a configuration file (ConfigParser-based,
> full
Ivan Sagalaev wrote:
> Standard Python logging configuration has
> a noticable gap between very simplistic basicConfig which configures
> only a root channel and a verbose imperative definition of handler
> objects, formatter objects and logger objects.
Forgot one thing. As it stands now Djang
Am 29.09.2009 um 04:07 schrieb Russell Keith-Magee:
>
> On Tue, Sep 29, 2009 at 12:44 AM, Johannes Dollinger
> wrote:
>>
Variable and FilterExpression will be deprecated as they require
the
caller to know the length of the expression in advance.
>>>
>>> I'm not sure I follow th
On Sep 29, 2:25 pm, Ivan Sagalaev wrote:
>
> Using WatchedFileHandler is a safe default because it works as
> FileHandler, just doesn't break with logrotate. I don't know of any
> disadvantages of WatchedFileHandler before the old FileHandler. So I
> don't think there's much value in giving peop
On Sep 29, 2:35 pm, Ivan Sagalaev wrote:
> Forgot one thing. As it stands now Django has this "historic" behavior
> when it imports and executes settings module twice. This results in
> breakage when you setup loggers and handlers by hand. We now circumvent
> this by having a helper function th
On Sep 29, 1:53 pm, Russell Keith-Magee
wrote:
>
> First off - let me reinforce that I'm in your camp here - I like
> Python's logger, and I think we should be adding logging to Django.
> Any hesitation I have expressed is mostly a function of institutional
> inertia, especially with regards to
On Tue, Sep 29, 2009 at 4:30 AM, Russell Keith-Magee
wrote:
...
> This trick is exactly what Django does internally when it constructs
> object instances. However, in the Django internals, it is a completely
> automated process - Django issues the query and parses the results, so
> there's no ris
Hmm. I just spent some time looking at #11828, and I don't think the
"syncing one db at a time" will work. The first problem this causes
is with anything that subscribes to the post sync signal. Content
type does this, so it can create permissions. If we sync one db at a
time, I don't see how
I've been using nose for our tests, and one of the features that I
really like is the ability to run the tests again but filter only the
ones that caused a problem.
I'm thinking it would look something like this
./manage.py test --failed
Does this sound worthwhile to anybody?
Rob
--~--~---
On Tue, Sep 29, 2009 at 11:48 AM, Rob Madole wrote:
>
> Hmm. I just spent some time looking at #11828, and I don't think the
> "syncing one db at a time" will work. The first problem this causes
> is with anything that subscribes to the post sync signal. Content
> type does this, so it can cre
On Sep 29, 9:36 am, Vinay Sajip wrote:
> Simon, I'm the author of Python's logging package. Sorry for the delay
> in replying, I've been away from this list awhile. I think the "Java
> heritage shines through" is just FUD.
Hi Vinjay,
Thanks for dropping by. Firstly, I'm sorry for disparaging of
On Sep 29, 2:24 am, SeanOC wrote:
> During the Djangocon sprints I started to work on a patch which would
> add a nicer interface for dealing with raw SQL queries. While there I
> talked to RKM about where it should fit into the ORM API and where in
> the code base should live. I've finally got
On Sep 18, 5:21 pm, Eric Holscher wrote:
> I have looked into Logging before for another project, and I found that
> SQLAlchemy's support seemed to be a pretty good model to follow. They define
> all of their loggers under the sqlalchemy namespace, and then you can
> configure different handlers
On Sep 29, 2:00 pm, Waylan Limberg wrote:
> The hard part is that basicConfig only works like that back to Python
> 2.4 yet Django supports 2.3. When I added logging to Python-Markdown,
> this was the hardest part. Figuring out how to configure logging so
> that it works in 2.3 as well. The docu
On Sep 29, 5:03 pm, Rob Madole wrote:
> I've been using nose for our tests, and one of the features that I
> really like is the ability to run the tests again but filter only the
> ones that caused a problem.
>
> I'm thinking it would look something like this
>
> ./manage.py test --failed
>
> Doe
On Tue, Sep 29, 2009 at 1:58 PM, Simon Willison wrote:
>
> On Sep 29, 5:03 pm, Rob Madole wrote:
>> I've been using nose for our tests, and one of the features that I
>> really like is the ability to run the tests again but filter only the
>> ones that caused a problem.
>>
>> I'm thinking it wou
> The first is that I'd like it to be compatible with deferred loading
> of model attributes - I haven't looked in to it, but my hunch is that
> this won't be too hard (it might even work in its present form without
> any further changes).
The current implementation doesn't support this. It wil
On Tue, Sep 29, 2009 at 1:58 PM, Simon Willison wrote:
>
> On Sep 29, 5:03 pm, Rob Madole wrote:
>> I've been using nose for our tests, and one of the features that I
>> really like is the ability to run the tests again but filter only the
>> ones that caused a problem.
>>
>> I'm thinking it wou
Yep, I use the pdb stuff too. That would be handy.
The way this works in nose is through the testid plugin. Typically you
do this:
nosetests --with-id --failed
This will create a file called .noseids in the current working
directory.
You can make it use something else by saying:
nosetests --
Ok, --failfast would be nice too :D, I think I remember seeing a
ticket on that. So make that 4 features from nose...
Which would be great if the test is third or fourth in the stack. If
it's the last test in 50, it would loose it's effectiveness.
I know, I know. If you are running 50 tests y
http://blog.jeffbalogh.org/post/57653515/nose-test-runner-for-django
It's certainly been done and doesn't require changes to Django.
On Sep 29, 1:34 pm, Rob Madole wrote:
> Ok, --failfast would be nice too :D, I think I remember seeing a
> ticket on that. So make that 4 features from nose...
>
On Sep 29, 7:34 pm, Rob Madole wrote:
> TEST_RUNNER = 'django.contrib.test.nose.run_tests'
>
> There might be some futzy bits to make that actually work, but I think
> it'd doable.
I'd love to see this working. Obviously this would work just as well
implemented as an external project - but if it
On Sep 29, 6:07 pm, Simon Willison wrote:
> Thanks for dropping by. Firstly, I'm sorry for disparaging of your
> work. I mis-spoke when I said the logging module wasn't "nicely
> designed" - I obviously don't believe that, since I'm very keen on
> including it in Django. I should have picked my
So I've read through the Python Logging 101 (really useful) and the
logging docs:
http://plumberjack.blogspot.com/2009/09/python-logging-101.html
http://docs.python.org/library/logging.html
Here's my understanding of what we need to do for Django.
1. Create a 'django' logger somewhere in the fr
I'll see if I can talk Jeff into adding what he's got as a start to
this. It looks solid to me.
Ticket and patches forthcoming...
On Sep 29, 2:47 pm, Simon Willison wrote:
> On Sep 29, 7:34 pm, Rob Madole wrote:
>
> > TEST_RUNNER = 'django.contrib.test.nose.run_tests'
>
> > There might be som
On Tue, Sep 29, 2009 at 8:56 PM, Rob Madole wrote:
>
> I'll see if I can talk Jeff into adding what he's got as a start to
> this. It looks solid to me.
>
> Ticket and patches forthcoming...
The nose test-runner that I'm currently using is at
http://gist.github.com/197593. (The code I point to
On Tue, Sep 29, 2009 at 6:29 PM, Simon Willison wrote:
>
[snip]
>
> By default, runserver would display no log messages at all.
Runserver currently outputs each request to the commandline. Any
reason that couldn't be handled by a logger? I seem to recall people
complaining that they couldn't red
On Wed, Sep 30, 2009 at 3:47 AM, Simon Willison wrote:
>
> On Sep 29, 7:34 pm, Rob Madole wrote:
>> TEST_RUNNER = 'django.contrib.test.nose.run_tests'
>>
>> There might be some futzy bits to make that actually work, but I think
>> it'd doable.
>
> I'd love to see this working. Obviously this wou
On Tue, Sep 29, 2009 at 9:31 PM, Jeff Balogh wrote:
> On Tue, Sep 29, 2009 at 8:56 PM, Rob Madole wrote:
>>
>> I'll see if I can talk Jeff into adding what he's got as a start to
>> this. It looks solid to me.
>>
>> Ticket and patches forthcoming...
>
> The nose test-runner that I'm currently u
46 matches
Mail list logo
