info('Timeout fetching feed %s' % url)
>
> In settings.py:
>
> MIDDLEWARE_CLASSES = (
> ...
> 'django.middleware.LogErrorsToWSGI', # write exceptions to
> wsgi.errors
> )
> LOGGING_MIDDLEWARE_LEVEL = 'info'
>
> # If you want cust
u
can have logging events collected in multiple locations. See the
Python documentation here for pointers:
http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this mes
lt handler for logging to file system.
Why "port it to Django"? Do you mean, copy it into Django? I'm not
sure it should be the default - not everybody uses logrotate. I'd
leave this sort of decision for code in settings.py.
Regards,
Vinay Sajip
--~--~-~--~~
I can see. Of
course there might be grievances - for example, people complain about
"slow". As a single logging call which just has a file handler is of
the order of some tens of microseconds, I don't know how bad this is -
what do we compare against? The To
on on how to do it right.
>
As I posted in an earlier response to Simon, I'm happy to help with
this.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" grou
technique within the Django world. It should
> definitely play nicely with any already-existant logging code.
+1, there are already patterns for doing this which work, involve no
need for django.contrib.log or similar and I'll happily work with the
st
- if it's felt that a lot of Django users are not Python-savvy enough
and need some hand-holding, then you'd perhaps need something like
this. I usually configure the logging system using its own
configuration file format (ConfigParser based, and supported by the
stdlib so no additio
t way for use with Django
particularly - just to make life easier for newbies and casual users.
Sure, an internal function would hide this from users.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
om-Python.
>
> I understand entirely the frustration of having a project perceived
> "the wrong way" by the public - Django Evolution has been stuck with a
> "magic" moniker for reasons that I can't begin to fathom. However, at
> the end of the day, you can&
where" in the application you want verbosity
turned up or down by thinking about apps and individual modules in
those apps.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
uestions. So please, raise any questions and/or issues on python-
list, bugs.python.org, Stack Overflow, etc.
Now I'll get off my soapbox.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
ing library is still
> available once they need it.
>
> So again, I apologise for my extremely poor choice of words - that was
> decidedly unclassy. I'm excited that you're interested in helping us
> integrate logging with Django in the best possible way.
>
No worri
On Sep 29, 11:29 pm, Simon Willison wrote:
>
> Here's my understanding of what we need to do for Django.
>
> 1. Create a 'django' logger somewhere in the framework that will
> always be executed if part of Django has been imported - would the
> django/__init__.py file work? Configure that with
logging module, thereby keeping Adrian happy :-)
>
> Seriously - I really do want to find out the nature of Adrian's
> objection to logging (if it is even current). I'd rather have an
> actual discussion than dance around a strawman.
It would perhaps be a problem if it was a
x27;s a bad idea if Django uses that
configuration automagically, as I said elsewhere on this thread.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
On Oct 4, 9:22 pm, Ivan Sagalaev wrote:
> I see one problem with explicitly calling a function from settings.py.
> This will execute instantiation of handlers and all the user staff very
> early when settings aren't fully configured yet. This prevents a user to
> have a handler that will use Dj
7/3.2.
However, to make it easy to use in Django and other systems which have
to work with older versions of Python, the functionality will be in
the form of a class (working title: DictConfigurator) which can just
be copied into Django (as has been suggested for other bits of
logging, such as Watc
h r10759 in May 09 and
though I haven't kept it updated recently, I have no problems
committing to doing any further work needed to get it into 1.2.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gr
impression from that statement that we had more
than just a few days to go. And I'm not sure that it matters anyway,
as from what I can tell, it's not really a core dev priority and the
main roadblock is lack of core dev time to discuss/guide around what
are perceived as outstanding issu
oday or tomorrow)".
Well, "begin voting" doesn't say anything about how long the polling
stations stay open :-)
> We are still open to new suggestions - Jacob's message was more of a
> "last call". However, at this late stage, new proposals will need to
>
the overall unit tests based on the
> microbenchmark.
You don't need to hack a logger to do this - you can just add a Filter
which passes everything but counts as it goes.
Anyway, the numbers don't look too bad at the moment :-)
Regards,
Vinay Sajip
--~--~-~--~~
edit one of the 'tagging's
to change the last part of the package name. This particular example
is not a real-world one, and obviously if I'd known that I was going
to use "django-tagging" at the outset and I was writing the other app
I could have named it to end with &qu
On Oct 11, 9:52 am, Russell Keith-Magee
wrote:
> On Sun, Oct 11, 2009 at 3:23 PM, Vinay Sajip wrote:
>
> This is true, but again, the distinction between theoretical and
> practical problem emerges. The set of mainstream apps in the wild is
> much larger than the set of in house
of which means that having a defined outcome
to compare against becomes problematic.
Of course if you have any specific thread-safety issue relating to
logging, then please raise an issue on the Python bug tracker and
attach a small script which illustrates the problem.
Regards,
Vinay Sajip
--~--~
k
you could just go ahead and mark #3591 as "wontfix" because that
effectively appears to be the situation. There are, I think, numerous
other tickets which have been closed as "wontfix" because "it's not a
real problem".
Regards,
Vinay Sajip
--~--~-~--~---
back and input from the core to make this happen. I'm just warning
> you (or whoever else tackles the problem) that it is going to be hard
> to get the attention of the core to fix a problem that not many people
> are having when there are plenty of other problems around.
Me
nstead of a tuple of
callables, you could have a tuple of (callable, args, kwargs) - but
that's detail. Is the basic idea workable?
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dj
;ve customized things.
You'll have to run django-admin.py, passing it your settings module.
(If the file settings.py does indeed exist, it's causing an
ImportError somehow.)"
We could certainly do with better error messages in such cases.
I'm not saying the
On Oct 13, 3:12 pm, Benjamin Slavin wrote:
> On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote:
> > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that
> > happens in db/models/loading.py - I thought it would be clear from my
> > saying I
e 0 errors. The logtest.log file shows that the listener was
registered and called back as expected. Here's the link to the log
file:
http://gist.github.com/209526
So, we can initialise logging, register a class_prepared listener, and
log some information when it's
o that model loading can be watched, then post app/model
loading to show that you can use models in the hooked code.
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&
ients don't response on 50% of last 50% within first
year of waiting"
Leaving aside the exact time frames and percentages which may well be
exaggerated, do you feel that the process is working so well that no
one is justified in feeling the frustration that's obviously being
expres
site. At other times,
we want to take advantage of a standard Django that our customers have
already got and are invested in, where there's no room for our
branched Django with those must-have (in our opinion) features. Then,
having our own bra
ngo is a high-profile project with lots of
goodness and loved by many, it's inevitable that people want to
contribute, and make it even better - there being many values of
better ;-). There are bottlenecks in the process (which I think the
core team acknowledges, but please say so if that&#x
existing fork looks like the only option.
How about using BitBucket? Does it have the same limitation? I see
there's already a Django mirror there:
http://bitbucket.org/mirror/django-all/
Regards,
Vinay Sajip
--~--~-~--~~~---~--~~
You received this message
I've submitted PEP 391 for review on python-dev, and this may have a
bearing on adding logging support to Django. Some of the discussions
involved using a dictionary defined in settings.py to configure
logging.
Regards,
Vinay Sajip
--
You received this message because you are subscribed t
On Dec 9, 11:32 am, reg...@messir.net wrote:
> As I understood logging support for django is complete now. Or not?
Not as far as I'm aware. Simon Willison has some experimental code on
GitHub AFAIK, and there's ticket 12012 tracking that implementation.
Regards,
Vinay Sajip
--
st be reached before any request
handling takes place is the reading of settings.py, so I based my
approach on that. From what I can see, the approach I've outlined is
not just suitable for setting up logging but also doing model-related
stuff such as listening for e.g. class_prepar
ing up logging but also doing model-related
stuff such as listening for e.g. class_prepared signals etc. from the
app loading machinery.
Here's a link to the October post:
http://groups.google.com/group/django-developers/msg/90b81d9f927d0bf0
Regards,
Vinay Sajip
--
You received this m
Further to my earlier post - I've put the whole branch on Launchpad:
https://code.launchpad.net/~vinay-sajip/django/logging
There's nothing much there at the moment, apart from some code as a
proof of concept. Tested with the following code tacked on at the end
of a vanilla settings.p
stantiate any logging object, including instances of
existing logging classes.
And, don't forget the Zen of Python - "Explicit is better than
implicit" ;-)
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developer
vailable).
I would welcome some feedback ... Launchpad branch is here:
https://code.launchpad.net/~vinay-sajip/django/logging
An example settings file which uses the functionality in the branch is
in the
second of the two posts mentioned above.
Regards,
Vinay Sajip
--
You received this messa
according to the cookie spec. This
comment on a Webkit bug has useful information:
https://bugs.webkit.org/show_bug.cgi?id=6063#c7
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
ty
apps, this means having to change settings.INSTALLED_APPS in those
apps as well, which is not ideal :-(
Also, I haven't merged this patch with trunk for almost a year, so
it's not necessarily "good to go" without at least doing that. Perhaps
when I get a bit of time, I'll be able t
- Original Message
> From: Guido van Rossum
> To: Jesse Noller
> Cc: Vinay Sajip ; python-...@python.org
> >> Assuming PEP 391 gets the nod, then after implementing the changes into
> Python, I plan to work with the Django community to get improved logging
>
On Feb 6, 1:02 pm, Ivan Sagalaev wrote:
> Thank you for your efforts!
You're welcome. And the PEP 391 functionality is already in Python svn
trunk (r77969), so feel free to download it and try it out.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to th
een a logical consequence
> of Step 1; if you're going to massively rewrite app loading, it would
> seem unusual to embed all the old problems in your rewrite.
>
I think that would all come out in the wash; for example the #3591
patch doesn't require a models.py, and the app i
s of at least some of the
issues, without leaping straight to implementation details: as a
result, it comes across as more considered.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
t page was referred to as containing what needed to be
addressed in a viable design.
>
> > Class-based applications? Can someone point me to some of those?
>
> django.contrib.admin is the most notable example.
>
Oh right, I thought you were talking about something else :-)
Rega
re a single application
> instance is returned with ``get_app``, another argument - ``path`` should be
> added. ``get_models`` and ``get_model`` would take an application instance
> and return models on that instance. This might affect the admin's handling of
> applications.
>
> Ti
a case of keeping the changes as small as
possible, at the time of the original patch. It's certainly better to
have models explicitly associated with apps - it would make some
things easier, especially in a multi-db setup.
Regards,
Vinay Sajip
--
You received this message because you are
On Apr 28, 1:11 pm, Hanne Moa wrote:
> the-real-solution-is-to-ditch-SMTP-ly yours,
> HM, postmaster
And your suggestion for a replacement would be ... what?
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers"
o's test
infrastructure, and I couldn't spot anything which refers to coverage
of Django's own code. If I've missed something blindingly obvious,
sorry for the bother, but a pointer would be appreciated!
Regards,
Vinay Sajip
--
You received this message because you are subscribed t
ranch which shows how logging can be easily
integrated during startup, and it's at
https://code.launchpad.net/~vinay-sajip/django/logging
It's a proof-of-concept, last merged with trunk in Jan 2010, but the
changes are simple so it shouldn't be a problem to bring up to date.
I'll lo
rally
used to do things such as presenting logging output as part of a page,
or to provide some Django-specific handlers (e.g. emailing via Django
configured mailer, rather than using logging's SMTPHandler) and
conventions for logging.
Regards,
Vinay Sajip
--
You received this message b
hon Wiki (http://
wiki.python.org/moin/LoggingPackage) which provides some rough
performance metrics. I have yet to see any substantive criticisms
based on actual measurements.
Just sayin',
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
&quo
ase.py (exception handling, including uncaught
exceptions)
django/db/backends/util.py (SQL statement execution)
django/core/handlers/wsgi.py (Unicode exception during request
handling)
Overall the changes are fairly modest and should be fairly easy to
review. Basic diffs to show what was added:
e sprints); if you're not, I'll
> try and review the code at some point and give you some feedback.
Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I
look forward to your feedback.
Regards,
Vinay Sajip
--
You received this message because you are subscrib
sqlfile'] },
},
}
That's using the PEP 391 schema which has been approved and
implemented in Python for 2.7/3.2. Obviously it's not the most minimal
configuration in this example - just something to illustrate multiple
log files (SQL and everything else) and the ability to set verb
hing else you may want to
> do on startup.
This implies that all the startup.py importing would be done in a
separate loop after all the model loading is done - i.e. the
equivalent of my POST_MODEL_CALLBACKS hook. If so, how could you hook
into class_prepared, as per my example? Can you con
) site.
> My current branch of django-experimental has a working implementation
> of the exception handling and query logging (lifted from simon's
> initial proposal).
>
Likewise in my Launchpad branch, though a little different in the
details from Simon's, though the effect is mu
fy their logging behaviour through this mechanism.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, se
verything else
that writes to stderr - not ideal.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, sen
h has the dictconfig
code) on a machine running Ubuntu Dapper, with Python 2.4, as that's
the minimum Python version requirement for Django now :-)
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
and - that's a personal preference and there's no point in
trying to sway anyone from their personal style preferences. But in
terms of meeting the functional requirement (both logging
configuration and the more general "do stuff on start-up once and once
only") and bang for bu
I've been having trouble accessing www.djangoproject.com recently,
from here in the UK. Is this a known problem? Is the server down?
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
27;s accessible now, but a lot slower
than usual. Thanks for the response, sorry for the noise.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegr
our comment about avoiding the model loading race condition is
> certainly a valid one, and that's probably enough to get me over the
> line on the need for this signal. My only concern is whether there is
> anything else that a "models_loaded" signal should be 'after
a general principle, hardwired
connections between specific databases and apps sounds broken to me,
too.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop
#x27;t understand what's "hardly a
> stretch" neither from context nor from dictionary.
"Hardly a stretch" == "Not exactly difficult"
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
"Django develop
ge.
I'd be happy to submit a patch - just wanted to canvass opinion here
before raising a ticket.
I raised this a few days ago on django-users - no response. Not sure
if that was the best place for the original post, so reposting here.
Sorry if it's not appr
veryone by improving the signal/noise ratio - how could this be
addressed?
I've only recently started using Django (yay!) and been trying to help
out triaging tickets, suggesting patches etc. in accordance with the
documented guidelines. Hope I'm not stepping on any toes. Please set
me straigh
turn up or down the verbosity of selected
chunks
of the framework, e.g.
logging.getLogger("django.contrib").setLevel(logging.DEBUG)
or
logging.getLogger("django.contrib.auth").setLevel(logging.DEBUG)
to affect all of the django contrib modules, or just the auth modules.
Regards,
Hi Fraser,
> > (a) Setting NOTSET on the root logger will cause absolutely everything
> > to go through the logging system - this could be unnecessary overhead as
> > well as being too much information.
>
> My reason for doing this was indeed to capture as much information as
> possible and then
> > What's the thinking on documentation-only patches? While they are just
> > as worthy of review and critical assessment as code patches, there is
> > less of a concern about affecting trunk stability, and less impact
> > analysis work needed.
>
> Not true. We try to be very careful about the do
es
if msgs:
open(potfile, 'ab').write(msgs)
if thefile != file:
This would appear to meet both of Malcolm's requirements. Shall I add
these patches to #1668 and re-open?
Regards,
Vinay Sajip
--~--~-~--~-
#x27; : 'my verbose
name' },
'app2' : { 'app_label' : 'my other label', 'verbose_name' : 'my
other verbose name' },
}
The values in the dict would, of course, be run through _() before
display.
Does any of this seem reasonable? I
27;ve done a lot
> of good research and thinking here, so let it bounce around in your head
> for a little while to see if anything good or bad pops up. Gives other
> people a little while to think about it, too.
Good advice, and I'll take it.
Regards,
Vinay Sajip
--~--~-~--
is need
not be internationalised.
(b) A verbose_name, which is used in the admin display. This should be
internationalised.
Both of these values can be suitably defaulted, as in Joseph's patch
for #3591.
I posted the above just to make sure my understanding is correct,
please set me straight i
I need some help with understanding some aspects of the above-named
functions. load_app is internal to loading.py and is called by both
get_apps and get_app to import a specific app module. But get_app(x)
first calls get_apps, which loads (using load_app) all the app modules
in INSTALLED_APPS. The
in this area, which shows up when
you run tests/runtests.py. get_apps() is called twice, first with a
set of "always-loaded" apps() and then with a whole load of test apps.
The second time around, get_apps() does nothing since _loaded was s
I'm working on an implementation of customisable app labels ( as per
http://code.djangoproject.com/ticket/3591 ) and making good progress.
Although it's a sizeable patch, when I run the test suite
(runtests.py), only two tests out of 107 fail. The two that fail are
both client tests that try to lo
Ignore my earlier ramblings. I just found create_default_site() and
found I wasn't hooking up to it correctly - don't know how I missed
that. All tests now pass!
Regards,
Vinay
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
or views and stored
procedures and schema migration, a more generic authorization scheme)
it looks as if there is work in various branches towards providing
more functionality in at least some of these areas.
My 2¢,
Vinay Sajip
--~--~-~--~~~---~--~~
You received t
he ready-
made admin interface, but development is often about trade-offs,
right? Django can't be all things to all people. Certainly, multi-db
and multiple database-authenticated connections are not the common
case, at least in my experience (and that's not a value judgement
about the
I have a similar question about the templating system. Are there any plans to
make it more standalone than it is at present? How would the current core
developers view any patches which might take the templating subsystem in the
direction of being completely standalone?
Regards,
Vinay Sajip
approached it just from the point of trying to
get the
tests to pass, and not (yet) focused on actually running realistic
scenarios.
Perhaps some of my fixes need changing - having other devs' eyeballs
on the
code can definitely help.
Please let me have your comments!
Regards,
Vinay Sajip
Sorry the formatting of the post got mangled - not sure what happened
there!
Regards,
Vinay Sajip
--
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 u
/GitHub), compared to the real
work still to be done in getting Django production-ready on 3.x.
Regards,
Vinay Sajip
--
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@googlegr
dling esp. in regexes is
another area where closer inspection would be worthwhile. The test
codebase contained a lot of Unicode literals (i.e. Unicode literals in
the source code, which would have been encoded in UTF-8 in the files
actually stored on disk) and I have converted these to use Unicode
e
s are acceptable to the core devs.
> Anyway, I'm trying to get into making the tests run and if I see some
> result from my work, will try to figure out some sync between github and
> bitbucket.
Great, we'd like to see what you find.
Regards,
Vinay Sajip
--
You receiv
le, the same literals being used over and
over again in copy/paste fashion, requiring patches in multiple
locations to add u() and b() wrappers, for example. I didn't have time
to rationalise this, as I was focused more on identifying and fixing
failures and errors.
Regards,
Vinay Sajip
-
On Nov 28, 7:14 pm, Vinay Sajip wrote:
> suite is a boon in this regard. Though having worked through the
> tests, it doesn't seem like the DRY principle is followed as much as
> it could be ... for example, the same literals being used over and
> over again in copy/paste f
mirror
at https://bitbucket.org/django/django - happy reviewing!
Regards,
Vinay Sajip
--
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
incorporates the very latest changes in Django SVN trunk
(r17165).
Regards,
Vinay Sajip
--
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
On Dec 2, 6:03 pm, Jacob Kaplan-Moss wrote:
>
> I'll try to spend the weekend writing/porting an app or two. If I can,
> I'll let you know how it goes.
That would be very useful feedback, thanks.
Regards,
Vinay Sajip
--
You received this message because you are subsc
is the area I am
working on currently - working in a virtualenv with distribute and a
PIL port installed.
You can certainly try helping with a PostgreSQL backend, I believe py-
postgresql can be used as a PostgreSQL driver under Python 3. Ian
Kelly mentioned on this thread that he'll be look
But don't all rush at once ;-)
Regards,
Vinay Sajip
--
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
ack. I can't do any testing at the
moment with an Oracle backend, unfortunately - but I can certainly
look at test failures under 3.x which succeed under 2.x to try and
eyeball fixes to problems.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Gr
On Dec 3, 8:50 pm, Karen Tracey wrote:
> On Fri, Dec 2, 2011 at 10:55 AM, Vinay Sajip wrote:
>
> > The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
> > the same codebase:
>
> What about Pythons 2.5 and 2.6?
I've done nothing intentionally that prev
1 - 100 of 213 matches
Mail list logo
