Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 12:42 AM, James Bennett <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: >> I'm always wondeing how it's possible that Django creators don't use >> django in ways that are written in django documentation. That leads to >> misunderstanding in expectations, and should explain why some tickets >> don't get expected resolutions. > > Adrian may not use it, but I certainly do, as do plenty of other folks > I know. Which means, I guess, that it's time for you to maybe stop > making sweeping generalizations and jumping to conclusions about > tickets based on someone simply saying he does or doesn't use some > particular feature a lot. Looks like James got up on the wrong side of the bed this morning, doesn't it? :-) Yuri, to answer your question: I try never to send the request object into a template context, except in rare cases like views/templates that do some sort of introspection -- like the Django debug view, for example. If I'm feeling like being DRY about media URLs, I just use a custom template tag or, if possible, template inheritance. Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
For all three of our projects in django, we've gone through and used our own exended version of render_to_response, which uses RequestContext by default. Its such a blessing. On Tue, Nov 18, 2008 at 7:42 PM, James Bennett <[EMAIL PROTECTED]>wrote: > > On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > > I'm always wondeing how it's possible that Django creators don't use > > django in ways that are written in django documentation. That leads to > > misunderstanding in expectations, and should explain why some tickets > > don't get expected resolutions. > > Adrian may not use it, but I certainly do, as do plenty of other folks > I know. Which means, I guess, that it's time for you to maybe stop > making sweeping generalizations and jumping to conclusions about > tickets based on someone simply saying he does or doesn't use some > particular feature a lot. > > > > -- > "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" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django documentation index redesigned
+1! Just one suggestion - if the final "bateries included" could be split into contrib apps, and core library that'd be nicer. On Tue, Nov 18, 2008 at 8:44 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > After months of being frustrated (and hearing other people being > frustrated) with our newish documentation index, I took some time > tonight to reorganize the links, to make it easier and faster to find > things. Take a look here: > > http://docs.djangoproject.com/en/dev/ > > I opted for a much more compact approach, with related links > side-by-side. The previous version tended to organize each link based > on whether it was reference vs. an overview, but this new version > organizes by topic, instead. > > The "Other batteries included" section is kind of a cop out. It's a > bit past my bedtime, so that's all I could come up with in a hurry. > > Hope people find this easier and faster to use! > > Adrian > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django documentation index redesigned
After months of being frustrated (and hearing other people being frustrated) with our newish documentation index, I took some time tonight to reorganize the links, to make it easier and faster to find things. Take a look here: http://docs.djangoproject.com/en/dev/ I opted for a much more compact approach, with related links side-by-side. The previous version tended to organize each link based on whether it was reference vs. an overview, but this new version organizes by topic, instead. The "Other batteries included" section is kind of a cop out. It's a bit past my bedtime, so that's all I could come up with in a hurry. Hope people find this easier and faster to use! Adrian --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > I'm always wondeing how it's possible that Django creators don't use > django in ways that are written in django documentation. That leads to > misunderstanding in expectations, and should explain why some tickets > don't get expected resolutions. Adrian may not use it, but I certainly do, as do plenty of other folks I know. Which means, I guess, that it's time for you to maybe stop making sweeping generalizations and jumping to conclusions about tickets based on someone simply saying he does or doesn't use some particular feature a lot. -- "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" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
RequestContext rarely used (branched from Feature reviews for 1.1)
Hi Adrian,
> * View-02 (Add RequestContext to render_to_response() by default): A
> ticket or mailing-list discussion wasn't linked-to on this one, so I'm
> going purely on the name of the change -- but I really don't like it.
> I rarely use RequestContext; I'd even feel comfortable saying I
> dislike it strongly. I would not like to see render_to_response()
> require it.
Well, since it's the preferred way to use MEDIA and some other vars
that should present in each html template, i'm wondering, how is it
possible you rarely use it?
Do you use template tags like {% media %} and similar?
How does your typical view function look like?
I'm always wondeing how it's possible that Django creators don't use
django in ways that are written in django documentation. That leads to
misunderstanding in expectations, and should explain why some tickets
don't get expected resolutions.
If you know more examples, could you please tell us. I'm sure it's not
only me who's interested in this.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Post about django optimizations
Hi guys, I wrote a post on django platform optimizations which i learned from building (still learning actually) kwippy (http://kwippy.com) , i would love to hear more tips from you guys out there :). http://www.desinerd.com/blog/technical/django-optimizations-within-the-platform/ Looking forward to *some* response. Dipankar [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Upgrading Trac?
On Mon, Nov 17, 2008 at 11:20 PM, Julien Phalip <[EMAIL PROTECTED]> wrote: > I know that this is likely to be a tricky/boring task and that it is > probably low-priority since we're on the way to 1.1, but I thought at > least I'd ask: Is there any plan in the short/mid term to upgrade > Trac? Every time I've upgraded Trac in the past it's been a major pain in the ass and eaten up a couple-three days of my time. And the 0.10 to 0.11 upgrade looks like it'll be even worse. So yeah, at some point I'll do the upgrade -- there's a new features we could take advantage of, and in general 0.11 is better than 0.10 in about every way -- but it'll have to wait until I can spare the time. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Upgrading Trac?
I know that this is likely to be a tricky/boring task and that it is probably low-priority since we're on the way to 1.1, but I thought at least I'd ask: Is there any plan in the short/mid term to upgrade Trac? My personal itch is that the current version (0.10.4) doesn't allow email obfuscation. I now exclusively use RSS feeds to track tickets but in the early days I used to use the CC field. And that has been the cause of an ongoing and significant amount of spam. Email obfuscation is available since version 0.11 [1]. That's my main concern about Trac but maybe someone else will bring up other good features that would justify an upgrade. Again, I understand it's low-priority and I won't push for it too hard. Cheers, Julien [1] http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature reviews for 1.1
On Thu, Nov 13, 2008 at 1:48 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I've also reviewed most of the features on the list. I'll talk about the > review process -- and how y'all can contribute -- below, but if you just wanna > see my thoughts, they're here: > http://spreadsheets.google.com/ccc?key=pSqnCvef6OXmGWQ9qbEVMeA. I've gone through and added my thoughts/ratings, here: http://spreadsheets.google.com/ccc?key=pOPN5bXOplmbl1EhSLhNBTg Fortunately, I have only a *few* differences with Jacob. :-) Unfortunately, I pasted Jacob's ratings in my own spreadsheet to try to compare, and that overwrote all of my comments, and the Google Spreadsheet "undo" wouldn't work. Argh! So, I'll rewrite my notes below. :-/ The major differences are: * Auth-02 (Allow for extendable auth_user module): I'm -1 on this. Any sort of framework-in-the-framework like this makes me suspicious, and the implementation and design would have to be incredibly solid. * Contrib-10 (Breadcrumbs): Seems a bit specialized for us. * Form-01 (Simon's DOCTYPE template fun): I like this a lot and think that the design is pretty sound. Let's make it happen. * ORM-05 (Identity map): I think that sharing select_related() objects would be a huge improvement, and that we can pull it off without inventing an entire identity map. * View-02 (Add RequestContext to render_to_response() by default): A ticket or mailing-list discussion wasn't linked-to on this one, so I'm going purely on the name of the change -- but I really don't like it. I rarely use RequestContext; I'd even feel comfortable saying I dislike it strongly. I would not like to see render_to_response() require it. Adrian --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
As long as you get the connection itself, i would think that would be sufficient, obviously the receiver should know which connection it is in the multi-db scenario, as it won't be able to just infer that based on the settings. On Nov 17, 6:15 pm, "Matthew D. Hancher" <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Matthew, would you mind sticking the script you used to test this up > > on dpaste? > > I'd love to, but it wasn't really a script per se, so much as a hodge- > podge that involved twiddling the server, restarting it, running some > tests, changing the server config again, and so forth. If I get a > moment to tidy it up into something dpasteable I'll do so. > > Jacob Kaplan-Moss wrote: > > <[EMAIL PROTECTED]> wrote: > >> Okay, I decided to do a bit of profiling to keep the conversation > >> moving. > > I did too; I took a stab at measure the raw speed of calling signals. > > Sweet. To the limited extent that our tests are comparable, they > appear to be in rough agreement. For example, they both show a signal > with a single trivial listener costing about nine times as much as a > signal with no listeners. > > Jacob Kaplan-Moss wrote: > > Given that, I'm generally going to be -1 on adding any non-essential > > signal to Django that's *connected by default* -- the overhead is too > > much, so internal uses should just use plain old function calls. > > However, I don't see that it's *too* bad to add a signal (like > > connection-created) with no listeners... but we should be careful in > > the documentation to clearly explain the substantial overhead > > involved. > > Okay. Given all this, how do people feel about a connection_created > signal? What about a cursor_created signal, either instead or in > addition? (I have no use case for that, but if for some reason people > prefer it to connection_created it will still be sufficient to solve > my immediate problem.) > > Malcolm Tredinnick wrote: > > A random thought: is there any other information worth sending along > > with the signal? Right now, the receiver is told "a connection was > > created". Anything that's likely to vary and that could be useful as a > > trigger for other actions? > > I was thinking about this, too. Right now the most important thing is > the type of database connection being created, which you can determine > from the sender, and which you can determine from settings anyway. > However, the big question in my mind is how all of this relates to the > multiple-database support that folks seem to be working on. Does > anyone from that camp want to chime in? > > Matt > > Matt Hancher > Intelligent Systems Division > NASA Ames Research Center > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Using pysqlite2 instead of sqlite3 when desired
Hi again, time for my next GeoDjango-on-SQLite question. In order to load the SpatiaLite extensions for SQLite, you first need to enable SQLite extensions in the first place. Unfortunately, pysqlite did not expose this functionality until pysqlite 2.5.0, which means it didn't make it into Python's sqlite3 module (which is essentially a snapshot of pysqlite 2.3.2, even in Python 2.6 ; I haven't checked Py3k). The same need arises if you want to use any other SQLite extensions, like the full-text-search extension. So, I'm trying to figure out the cleanest way to let users take advantage of a newer pysqlite2 if it's present, since currently Django always uses sqlite3 if it's there. The original reason for making sqlite3 the default was to "to do the right thing first and fallback" (#2772), which made the (seemingly reasonable) assumption that sqlite3 would become the undisputed correct name in the future. Unfortunately, the package itself retained the pysqlite2 name, and only the Python-internal snapshots (which will inevitably become outdated) have the sqlite3 name. Options include: A. Leave sqlite3 as the default, and add a configuration setting that forces use of pysqlite2 if desired. B. Always try both sqlite3 and pysqlite2, and use whichever has the greater version number if both are present. C. Same as B, but with an optional configuration option to force one or the other if desired. D. Switch to making pysqlite2 the default, since that's the correct name for the module if the user has explicitly installed it, and treat the Python-bundled version as the fallback. E. Develop arbitrarily convoluted bits of logic that pay attention to e.g. what Python version we're running under or the phase of the moon or something. I think I'm personally slightly inclined towards C, but I would be happy with B or D. I don't really like A because I worry that the sqlite3 module will become increasingly outdated and this configuration option will be an extra step and source of confusion for new users. But users would already be forced to think about the issue when installing pysqlite2 in the first place, so A would not be the end of the world either, and it does minimize the chance of accidentally breaking users with partially-broken pysqlite2 installations that Django is currently blissfully ignoring. Thoughts? If there's a consensus on an approach, then I can open a ticket with a patch Matt Matt Hancher Intelligent Systems Division NASA Ames Research Center [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Improving Errors from manage.py
On Mon, Nov 17, 2008 at 3:49 PM, David Cramer <[EMAIL PROTECTED]> wrote: > Ahh. I suppose that makes sense. Is there any reason it doesn't show > them by default? Because they're hard to read and scary for folks not familiar with Python. "I just typed this one thing and got twenty lines of error messages!" Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Improving Errors from manage.py
On Mon, Nov 17, 2008 at 3:41 PM, David Cramer <[EMAIL PROTECTED]> wrote: > I've been trying to dump some data to fixtures for the last couple > days, and I've ran into various problems each time. It's been quite > difficult each time to determine the problems, as there's no useful > tracebacks on the error messages: > > [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpdata > businesses > data > Error: Unable to serialize database: Category matching query does not > exist. David, you've been around here long enough to know that this is a question for django-users. Direct these usage question there. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
On Mon, Nov 17, 2008 at 4:14 PM, matt westerburg <[EMAIL PROTECTED]> wrote: > Is there any documentation as to why Django is not threadsafe? It just > seems to me that with the Global Interpreter Lock and all, it would be > threadsafe. That wouldn't as nice as "really-really thread safe". You know, there are GIL-less Python implementations out there ;-) -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
[EMAIL PROTECTED] wrote: > Matthew, would you mind sticking the script you used to test this up > on dpaste? I'd love to, but it wasn't really a script per se, so much as a hodge- podge that involved twiddling the server, restarting it, running some tests, changing the server config again, and so forth. If I get a moment to tidy it up into something dpasteable I'll do so. Jacob Kaplan-Moss wrote: > <[EMAIL PROTECTED]> wrote: >> Okay, I decided to do a bit of profiling to keep the conversation >> moving. > I did too; I took a stab at measure the raw speed of calling signals. Sweet. To the limited extent that our tests are comparable, they appear to be in rough agreement. For example, they both show a signal with a single trivial listener costing about nine times as much as a signal with no listeners. Jacob Kaplan-Moss wrote: > Given that, I'm generally going to be -1 on adding any non-essential > signal to Django that's *connected by default* -- the overhead is too > much, so internal uses should just use plain old function calls. > However, I don't see that it's *too* bad to add a signal (like > connection-created) with no listeners... but we should be careful in > the documentation to clearly explain the substantial overhead > involved. Okay. Given all this, how do people feel about a connection_created signal? What about a cursor_created signal, either instead or in addition? (I have no use case for that, but if for some reason people prefer it to connection_created it will still be sufficient to solve my immediate problem.) Malcolm Tredinnick wrote: > A random thought: is there any other information worth sending along > with the signal? Right now, the receiver is told "a connection was > created". Anything that's likely to vary and that could be useful as a > trigger for other actions? I was thinking about this, too. Right now the most important thing is the type of database connection being created, which you can determine from the sender, and which you can determine from settings anyway. However, the big question in my mind is how all of this relates to the multiple-database support that folks seem to be working on. Does anyone from that camp want to chime in? Matt Matt Hancher Intelligent Systems Division NASA Ames Research Center [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Improving Errors from manage.py
Ahh. I suppose that makes sense. Is there any reason it doesn't show them by default? On Nov 17, 3:45 pm, "Alex Koshelev" <[EMAIL PROTECTED]> wrote: > Try to use `--traceback` switch that prints exception's traceback > > On Tue, Nov 18, 2008 at 00:41, David Cramer <[EMAIL PROTECTED]> wrote: > > > I've been trying to dump some data to fixtures for the last couple > > days, and I've ran into various problems each time. It's been quite > > difficult each time to determine the problems, as there's no useful > > tracebacks on the error messages: > > > [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpdata > > businesses > data > > Error: Unable to serialize database: Category matching query does not > > exist. > > > While this is great and all (it beats the "recursive error" that > > appeared in previous revisions with the same models), it would be much > > more useful if some of the commands would give more detailed > > information so that you can actually diagnose problems :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Improving Errors from manage.py
Try to use `--traceback` switch that prints exception's traceback On Tue, Nov 18, 2008 at 00:41, David Cramer <[EMAIL PROTECTED]> wrote: > > I've been trying to dump some data to fixtures for the last couple > days, and I've ran into various problems each time. It's been quite > difficult each time to determine the problems, as there's no useful > tracebacks on the error messages: > > [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpdata > businesses > data > Error: Unable to serialize database: Category matching query does not > exist. > > > While this is great and all (it beats the "recursive error" that > appeared in previous revisions with the same models), it would be much > more useful if some of the commands would give more detailed > information so that you can actually diagnose problems :) > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Improving Errors from manage.py
I've been trying to dump some data to fixtures for the last couple days, and I've ran into various problems each time. It's been quite difficult each time to determine the problems, as there's no useful tracebacks on the error messages: [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpdata businesses > data Error: Unable to serialize database: Category matching query does not exist. While this is great and all (it beats the "recursive error" that appeared in previous revisions with the same models), it would be much more useful if some of the commands would give more detailed information so that you can actually diagnose problems :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
Matthew, would you mind sticking the script you used to test this up on dpaste? Alex On Nov 17, 3:01 pm, "Matthew D. Hancher" <[EMAIL PROTECTED]> wrote: > On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > > I know this is a horribly nebulous question (like all benchmarking), > > and it's completely dependent on the speed of your machine and a > > million other factors. However, if we are going to start adding > > signals to very common operations (like m2m and opening connections), > > we need to know what sort of overhead we are adding in absolute terms. > > Okay, I decided to do a bit of profiling to keep the conversation > moving. None of this is particularly rigorous stuff, but I figure > it's a start. > > (The uncertainties shown below are the standard deviations across > repeated runs divided by the square root of the number of runs, with > ten-percentile thresholds for outlier rejection, all of which makes > for a rough but useful measure. This was all on my development > machine, not a pristine test environment (which I don't have), so lord > knows what external factors may have been involved.) > > I began by examining the impact of adding the connection_created > signal in a toy end-to-end test, with a local client requesting a > reasonably normal page from a simple blog app, using sqlite3 and the > development server. The signal listeners here were pretty simple, > just incrementing a connection counter. Here is what I saw. > > Page request performance, in seconds per 100 queries: > trunk (no listeners): 2.624 +/- 0.009 > 6064 (no listeners): 2.624 +/- 0.005 > 6064 (1 listener): 2.624 +/- 0.006 > 6064 (100 listeners): 2.680 +/- 0.005 > > The differences (or lack thereof) between the first three timings here > are not statistically significant, but it is clear that by the time I > get to 100 listeners I'm seeing a real performance hit. In order to > better measure the impact of adding the signal even when no listeners > are present, I zoomed in on the database connection/disconnection > cycle itself (again using sqlite3 with a database on disk). > > Database connect/close performance, in seconds per 1 cycles: > trunk (no listeners): 1.5664 +/- 0.0010 > 6064 (no listeners): 1.5895 +/- 0.0011 > 6064 (1 listener): 1.7115 +/- 0.0015 > 6064 (100 listeners): 4.5087 +/- 0.0036 > > So, adding the connection_created signal had a roughly 1% impact on > the speed of the connection/disconnection cycle, and adding a fairly > simple listener to that signal resulted in a total of a 9% impact. > > Now we can put the pieces together to get a little bit of > perspective. Evidently the database connection/disconnection cycle > accounts for roughly 0.6% of the processing time for the query in > question (on this computer, with this configuration). We can use this > to estimate the impact on the page request performance. > > Estimated impact of 6064 on page request performance: > 6064 (no listeners): 0.009% > 6064 (1 listener): 0.055% > 6064 (100 listeners): 1.12% (measured 2.13% +/- 0.54%) > > There's a fair amount of hand-waving involved in those estimates, but > by looking at the 100-listener case (where the impact on page requests > was measurable) we can see that the estimate lands us within a factor > of two of the measured value. The difference could be explained in > any number of ways, but the upshot is that a true impact of 0.02% or > more on page requests for the no-listener case would be very plausible. > > Matt > > Matt Hancher > Intelligent Systems Division > NASA Ames Research Center > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
On Mon, Nov 17, 2008 at 2:01 PM, Matthew D. Hancher <[EMAIL PROTECTED]> wrote: > Okay, I decided to do a bit of profiling to keep the conversation moving. I did too; I took a stab at measure the raw speed of calling signals. My code's at http://gist.github.com/25892; the output looks like: Nothing : 0.00283 (0.00028 percall) Plain func call : 0.07054 (0.00705 percall) Signal; 0 handlers: 0.09331 (0.00933 percall) Signal; 1 handler : 0.79125 (0.07912 percall) Signal; 10 handlers: 3.36051 (0.33605 percall) Signal; 100 handlers: 27.56269 (0.000275627 percall) The raw numbers are pretty much useless (run on a machine while doing about seventy other things), but you can see that: * In Python, calling a function (``handle()``) takes 25 times as long as doing nothing (``pass``). * Dispatching a signal when there's no handlers is about 1.3 times a function call. * Dispatching a signal when there's one handler is about 11 times the cost of a function call. * Addition of additional receivers scales linearly. This is about what I'd expected: calling a un-handled signal is extremely cheap -- 1.3x the function overhead is as close to free as you can get. The first listener is expensive; remaining ones cost O(N) time. Given that, I'm generally going to be -1 on adding any non-essential signal to Django that's *connected by default* -- the overhead is too much, so internal uses should just use plain old function calls. However, I don't see that it's *too* bad to add a signal (like connection-created) with no listeners... but we should be careful in the documentation to clearly explain the substantial overhead involved. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Notification on new database connections (ticket #6064)
On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > I know this is a horribly nebulous question (like all benchmarking), > and it's completely dependent on the speed of your machine and a > million other factors. However, if we are going to start adding > signals to very common operations (like m2m and opening connections), > we need to know what sort of overhead we are adding in absolute terms. Okay, I decided to do a bit of profiling to keep the conversation moving. None of this is particularly rigorous stuff, but I figure it's a start. (The uncertainties shown below are the standard deviations across repeated runs divided by the square root of the number of runs, with ten-percentile thresholds for outlier rejection, all of which makes for a rough but useful measure. This was all on my development machine, not a pristine test environment (which I don't have), so lord knows what external factors may have been involved.) I began by examining the impact of adding the connection_created signal in a toy end-to-end test, with a local client requesting a reasonably normal page from a simple blog app, using sqlite3 and the development server. The signal listeners here were pretty simple, just incrementing a connection counter. Here is what I saw. Page request performance, in seconds per 100 queries: trunk (no listeners): 2.624 +/- 0.009 6064 (no listeners): 2.624 +/- 0.005 6064 (1 listener): 2.624 +/- 0.006 6064 (100 listeners): 2.680 +/- 0.005 The differences (or lack thereof) between the first three timings here are not statistically significant, but it is clear that by the time I get to 100 listeners I'm seeing a real performance hit. In order to better measure the impact of adding the signal even when no listeners are present, I zoomed in on the database connection/disconnection cycle itself (again using sqlite3 with a database on disk). Database connect/close performance, in seconds per 1 cycles: trunk (no listeners): 1.5664 +/- 0.0010 6064 (no listeners): 1.5895 +/- 0.0011 6064 (1 listener): 1.7115 +/- 0.0015 6064 (100 listeners): 4.5087 +/- 0.0036 So, adding the connection_created signal had a roughly 1% impact on the speed of the connection/disconnection cycle, and adding a fairly simple listener to that signal resulted in a total of a 9% impact. Now we can put the pieces together to get a little bit of perspective. Evidently the database connection/disconnection cycle accounts for roughly 0.6% of the processing time for the query in question (on this computer, with this configuration). We can use this to estimate the impact on the page request performance. Estimated impact of 6064 on page request performance: 6064 (no listeners): 0.009% 6064 (1 listener):0.055% 6064 (100 listeners): 1.12% (measured 2.13% +/- 0.54%) There's a fair amount of hand-waving involved in those estimates, but by looking at the 100-listener case (where the impact on page requests was measurable) we can see that the estimate lands us within a factor of two of the measured value. The difference could be explained in any number of ways, but the upshot is that a true impact of 0.02% or more on page requests for the no-listener case would be very plausible. Matt Matt Hancher Intelligent Systems Division NASA Ames Research Center [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.1, app() and ticket #3591
On Nov 17, 10:31 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> Importing in the settings.py is effectively not required by any other
> part of Django.
Is importing in settings.py regarded generally as bad practice? If so,
I wasn't aware of this.
> What do you mean by "which you don't control"? I
> clearly control what in AUTHENTICATION_BACKENDS, FILE_UPLOAD_HANDLERS,
> MIDDLEWARE_CLASSES, SESSION_ENGINE, TEMPLATE_CONTEXT_PROCESSORS and
> TEMPLATE_LOADERS is, which are *all* imported somewhere else.
>
I just meant that you don't get to control exactly when the import
happens. I know that circular imports are a thing to watch out for in
Django, so to some extent there is some import magic that still goes
on.
> Well, that would also be the workflow in my case since an App class
> would only be needed *if* you want to override default values. Just
> like you are able to override ModelAdmin classes et al right now.
> That's why I called it a strong paradigm in Django.
But you can also use ModelAdmin instances, and as far as I know it's
perfectly OK to do that, too. (Please correct me if I'm wrong.)
> Of course imports are essential -- except the settings.py which is
> mostly used as a plain config that happens to be pure Python. I'm not
> saying nor implying that imports are harmful in general.
>
But you seem to be saying that all imports are harmful in settings.py.
In the http://code.djangoproject.com/wiki/InstalledAppsRevision page,
the snippet of code at the start
INSTALLED_APPS = Apps(
app('django.contrib.admin'),
app('project.app', name='polls'),
)
could not be achieved without some import to bind the names Apps and
app, could it?
>
> This site specific code can live anywhere in your PYTHONPATH, for
> example in the 'app' module of a 'tralala' package. This package could
> also hold other site-specific things like templates, templatetags,
> custom ModelAdmin class, custom forms, custom URLs etc.
[snip]
> Since you want to override an existing 3rd party app, the code
> defining MyAuthApp and MyCommentApp would live somehwere in the Python
> path. The 'tralala' package in my example is a site-specific app that
> could contain its own models of course but could also be the holder of
> the app classes for overriding, conveniently saved in the 'app'
> submodule.
Ok, I see what you're getting at now. I had another look at the
http://code.djangoproject.com/wiki/InstalledAppsRevision page and in
another post on this thread, in a reply to Malcolm, I've said more
about the issues described on that page. Waiting for feedback now...
Thanks & 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django 1.1, app() and ticket #3591
On Nov 17, 11:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > The InstalledAppsRevision wiki page. That was produced after the PyCon > sprint. Since that involved a bunch of people, a number of them > maintainers, I tend to view it as fairly canonical as to what is wanted > in the feature. I see now. I've had a look at that page before, and looked at it again after it was mentioned by Jannis in this thread. It's hard to tell which are just ideas for discussion, and which are lines in the sand, so to speak, from the POV of the core devs. For example, the desire to support multiple instances of one app is mentioned as a design goal, but the difficulty of supporting this feature is highlighted on the page. So one example of the clarity I am looking for from the core devs is, is the support of multiple instances of any app an absolute given? Or is it a nice-to-have? Jannis couldn't recall the exact use case for having multiple-app-instance support, and to me it seems to be a nice-to-have rather than a must-have. It may have been that this was a design goal at the outset, but it's not clear whether any trade- off should be made such as "let's drop multiple-instance-of-same-app as a requirement, the effort required to provide it is not worth the benefit it confers". The Wiki page correctly points out that many things in Django are model-centric (model._meta) rather than app-instance-centric, which leads to some of the difficult issues which rear their heads. To deal with these issues squarely, perhaps some more thorough rearrangement of the app loading machinery may be needed, but of necessity it will probably touch more parts of the code. This, I know from experience, will be a harder sell. To quote Jacob from 5 December 2007: > http://code.djangoproject.com/ticket/3591 has been following this > problem (and the other, related ones). The patches there look > relatively good and the tests appear to pass, but I'm concerned about > the level of boat-rocking this patch introduces (it basically redoes > the entire app/model loading mechanism in the process). The AppCache stuff which was added by you in r5922 on 18 Aug 2007 reworked the app/model loading mechanism a fair bit, and I can't see the #3591 patch as being in a different league of boat-rocking. It does touch more files, but most of the changes are very similar to each other and not hard to understand. Obviously my work is not to be trusted to the same extent as yours, but it did pass all tests then and still does now. So at the time Jacob made his comment, there was no reason other than gut feeling or lack of time for not looking at it further; there were no specific comments made on the patch at that time. If that sounds a bit like a moan, it's not meant to - it's just a plea for more specific criticism. I feel that any more far-reaching work which is not blessed or at least guided in advance by the core devs may be rejected later because they judge it as too much of a boat-rocker, or in some other way doesn't fit in with their thinking. Of course they are entirely within their rights to make these kind of value judgements - it's even a responsibility, I would say. So, how to move things forward? Let's assume that core devs are open to any reasonable solution, and put a stake in the ground by making the following assertion, to invite some feedback: "The Django app is a concept which is well understood in the Django community. We can talk about the properties of an app just like we would with any Django model - for example their templates, their media, their verbose name, their database table prefix, their models, their permissions, etc. etc. However, there is no corresponding software construct which models the mental abstraction, which restricts the ability to build upon this important concept in the software we build. Therefore, it would be a Good Thing to have an App class to model a Django application, and an InstalledApps class to model a list of installed applications in a site. The InstalledApp class, through its single instance, would allow apps to be located by a unique (to the Django installation) label. The App class would allow a site developer to bring together multiple apps from different third parties and to override certain default properties of those apps, such as database table or permission prefixes, to allow apps to be disambiguated and internationalised as per the requirements of the Django installation. In order for this to be achieved, the code which presently obtains information from the model - such as the database prefix - must be refactored to scan the applications using the methods defined in the InstalledApps and App classes. The default implementations of these methods should fetch the information from the current source, e.g. a model's _meta, except where explicitly configured otherwise in the site configuration. The InstalledApps and App classes should be kept as lightweight as possible, with methods (apar
Re: Multi-Threaded Dev Server
On Mon, Nov 17, 2008 at 10:54 AM, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > There are bugs. Django isn't thread-safe, and we know that. Um... That's just not true. At one point (two years ago?) it wasn't, but these days Django's deployed all over the place in mutli-threaded situations. If it wasn't threadsafe we'd hear about it. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
Is there any documentation as to why Django is not threadsafe? It just seems to me that with the Global Interpreter Lock and all, it would be threadsafe. I don't intend to start a flame, I am just curious about learning why this might be. I am favor of the mutlitprocess approach layed out by Ludvig. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
On Nov 16, 2008, at 07:26, Chris wrote: > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > threading, especially when it could be very useful. We don't even know > if there are multi-threading bugs. And even if there are, they can be > fixed. There are bugs. Django isn't thread-safe, and we know that. The best solution I can come up with would be to use the type of multitasking given by the processing library in py2.6. http://pypi.python.org/pypi/processing Ludvig Ericson --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-Threaded Dev Server
The last thing new people need when they come in and start playing around with the dev server is to worry about all the issues that can come up with threading. I would never recommend to anyone who doesn't really know what they're doing and anyone who does can easily use any one of the number of solutions other than the dev server to test those setups. Keep it simple. Keep everyone sane. Even if it was added as some optional flag, I can guarantee that a number of people without enough of an understanding of threads are just going to enable it when they read about it thinking "threads make it faster" and thinking no more about it. I strongly urge this to not be added to what should be a simple dev server. On Sun, Nov 16, 2008 at 8:44 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > I think I may have to actually agree that multi-threading is somewhat > needed, since it does limit these kind of features from working. I, > however, would deem it less a priority than most thing. If you can > write a patch for it (or if one exists, I didn't look) though, I don't > see any reason to not extend runserver to use it. > > On Nov 16, 6:45 am, Steve Holden <[EMAIL PROTECTED]> wrote: >> Julian wrote: >> > [...] I think some people want to use snippets like that [...] >> >> Wouldn't you agree that's a pretty feeble use case for something as >> potentially disruptive as multi-threaded serving? Particularly when the >> CherryPy alternative is so readily available. >> >> regards >> Steve >> -- >> Steve Holden+1 571 484 6266 +1 800 494 3119 >> Holden Web LLC http://www.holdenweb.com/ > > > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.1, app() and ticket #3591
On Mon, 2008-11-17 at 02:24 -0800, Vinay Sajip wrote: > > > On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > My -1 is because of basically the same thing Jannis has pointed out (and > > as I mentioned in my comment). There's a big ticket with various > > proposals and at some point last year Adrian mentioned he had another > > idea and that led to a group discussion at PyCon this year which raised > > a bunch of issues to be resolved. I don't feel there's a great consensus > > about the approach yet. This isn't something that should be half-baked, > > so if there's still unresolved items with no buy-in from any maintainer > > (and I haven't seen that yet), then I'm not going to be in favour. > > > > I just don't think there's enough detail in your comments - maybe I'm > just being thick :-( You say "the same thing as Jannis has pointed > out" - which thing is that exactly, sorry if I'm being dense? The InstalledAppsRevision wiki page. That was produced after the PyCon sprint. Since that involved a bunch of people, a number of them maintainers, I tend to view it as fairly canonical as to what is wanted in the feature. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.1, app() and ticket #3591
>> Indeed, my idea though is to dodge imports in settings.py and just
>> use
>> dotted module names.
>
> I'm not sure why importing in settings.py is such a bad thing. Putting
> in dotted module names just moves the importing to somewhere else
> (which you don't control) and seems more 'magical'.
Importing in the settings.py is effectively not required by any other
part of Django. What do you mean by "which you don't control"? I
clearly control what in AUTHENTICATION_BACKENDS, FILE_UPLOAD_HANDLERS,
MIDDLEWARE_CLASSES, SESSION_ENGINE, TEMPLATE_CONTEXT_PROCESSORS and
TEMPLATE_LOADERS is, which are *all* imported somewhere else.
>> The settings.py would contain a list of one of the following:
>>
>> 1. a dotted module name to a module representing an app, like
>> 'django.contrib.admin'
>> 2. a dotted module name to an App subclass representing an app, like
>> 'tagging.app.TaggingApp'
>>
>> INSTALLED_APPS = (
>> 'django.contrib.auth',
>> 'django.contrib.contenttypes',
>> 'django.contrib.sessions',
>> 'django.contrib.admin',
>> 'tagging.app.TaggingApp',
>> 'timezones.app.TimezoneApp',
>> 'satchmo',
>> )
>>
>> This is how the AppCache is filled with App instances:
>>
>> 1. On startup the AppCache tries to import each of the entries in the
>> INSTALLED_APPS setting.
>> a. If the result is an App subclass: yay!
>> b. If the result is a module (like > 'django.contrib.admin'>): look in the 'app' submodule for App
>> subclass(es)
>> c. If neither was found use the base App class
>> 2. Things like get_model and get_app would take the full dotted
>> module
>> name instead of the app_label.
>>
>
> I see. It seems a little odd to have app classes in a submodule of an
> app itself. To me, the ideal situation from a reusable apps
> perspective would be - get some apps, put them on the import path,
> make changes to settings.py (which is where I'm assembling the apps
> used on my site) and configure for disambiguation if needed.
Well, that would also be the workflow in my case since an App class
would only be needed *if* you want to override default values. Just
like you are able to override ModelAdmin classes et al right now.
That's why I called it a strong paradigm in Django.
> I'm not sure it's such a good idea to use the dotted module name
> everywhere instead of the app label: it's handier to have the app
> label.
Agreed, that part needs thinking.
>> Imports are required for no other extensible feature of Django --
>> while they are required to use derived app classes in your idea. I
>> think that has a simple reason: it keeps the implementations separate
>> and the settings clean of complex code. Something that is very
>> helpful
>> for users, I think.
>
> Imports are bread and butter to Python applications, including Django,
> and it seems a little doctrinaire to object to them just because
> they're not used for everything. As I understand it, it's perfectly
> good practice to use functions rather than function names in urlconfs.
> Perhaps the core devs could pronounce on "imports considered harmful"
> or someone could point me to such a pronouncement ...
Of course imports are essential -- except the settings.py which is
mostly used as a plain config that happens to be pure Python. I'm not
saying nor implying that imports are harmful in general.
>> Somewhere in your site specific code (preferable app.py) you would
>> create something this to override thing from 3rd party apps:
>>
>> from tagging.app import TaggingApp
>> from django.utils.translation import gettext_lazy as _
>>
>> class MyTaggingApp(TaggingApp):
>> db_prefix = 'my_tagging'
>> verbose_name = _('my tagging')
>> #..
>>
>> In your settings.py you would add:
>>
>> INSTALLED_APPS = (
>> # ..
>> 'tralala.app.MyTaggingApp',
>> # ..
>> )
>>
>
> Where does this site specific code live? I would like to put all my
> code in reusable apps where possible, and site configuration code in
> settings. Is this good practice, and if not what is the better
> practice?
This site specific code can live anywhere in your PYTHONPATH, for
example in the 'app' module of a 'tralala' package. This package could
also hold other site-specific things like templates, templatetags,
custom ModelAdmin class, custom forms, custom URLs etc.
>> from django.core.apps.base import App
>> from django.utils.translation import gettext_lazy as _
>>
>> class MyAuthApp(App):
>> app_label = 'tp_auth'
>> verbose_name = _('my auth')
>> module_name = 'third.party.app1.package.path.ends.in.auth'
>>
>> class MyCommentsApp(App)
>> app_label = 'tp_comments'
>> verbose_name = _('my comments')
>> module_name = 'third.party.app2.package.path.ends.in.comments'
>>
>> Then in settings.py:
>>
>> INSTALLED_APPS = (
>> # ..
>> 'tralala.app.MyAuthApp',
>> 'tralala.app.MyCommentsApp',
>> # ..
>> )
>>
>> The AppCache would get the models from the module_name in case it's
>> provided
Re: Django 1.1, app() and ticket #3591
On Nov 17, 1:13 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > My -1 is because of basically the same thing Jannis has pointed out (and > as I mentioned in my comment). There's a big ticket with various > proposals and at some point last year Adrian mentioned he had another > idea and that led to a group discussion at PyCon this year which raised > a bunch of issues to be resolved. I don't feel there's a great consensus > about the approach yet. This isn't something that should be half-baked, > so if there's still unresolved items with no buy-in from any maintainer > (and I haven't seen that yet), then I'm not going to be in favour. > I just don't think there's enough detail in your comments - maybe I'm just being thick :-( You say "the same thing as Jannis has pointed out" - which thing is that exactly, sorry if I'm being dense? Please can you point us to a reference to Adrian's idea, the PyCon discussion and the issues which need to be resolved? If you're referring to #3591 as the big ticket, I don't see why you see it as big, and since the patch of 3 May 2007 I don't see any vastly different proposals which could be described as competing - just variations on a theme/minor suggestions for improvement. If there's no emerging consensus about the approach, I would say it's because no core dev has made any definitive, specific comments about what's on the table already. We know you guys are busy, and there are definitely bigger fish to fry, but if you could just give us some pointers as to where exactly the current patch fails to float your boat, that would be a big help. > I'm examining the concept as a whole, not the lines of code at the > moment. Remember that "no, right now" doesn't mean "no, forever". > That's good to know. In examining the concept as a whole, what are the goals as you see them? What requirements/issues have not been captured, which might lead you to conclude that the lines of code are not worth bothering with yet? Thanks, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.1, app() and ticket #3591
On Nov 17, 12:50 am, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>
> The two -1 from core devs veto the feature for the next version, not
> the whole feature. We can go on discussing it here. I still hope they
> chime in though :)
>
I hope so too.
>
> Indeed, my idea though is to dodge imports in settings.py and just use
> dotted module names.
>
I'm not sure why importing in settings.py is such a bad thing. Putting
in dotted module names just moves the importing to somewhere else
(which you don't control) and seems more 'magical'.
>
> The settings.py would contain a list of one of the following:
>
> 1. a dotted module name to a module representing an app, like
> 'django.contrib.admin'
> 2. a dotted module name to an App subclass representing an app, like
> 'tagging.app.TaggingApp'
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.admin',
> 'tagging.app.TaggingApp',
> 'timezones.app.TimezoneApp',
> 'satchmo',
> )
>
> This is how the AppCache is filled with App instances:
>
> 1. On startup the AppCache tries to import each of the entries in the
> INSTALLED_APPS setting.
>a. If the result is an App subclass: yay!
>b. If the result is a module (like 'django.contrib.admin'>): look in the 'app' submodule for App
> subclass(es)
>c. If neither was found use the base App class
> 2. Things like get_model and get_app would take the full dotted module
> name instead of the app_label.
>
I see. It seems a little odd to have app classes in a submodule of an
app itself. To me, the ideal situation from a reusable apps
perspective would be - get some apps, put them on the import path,
make changes to settings.py (which is where I'm assembling the apps
used on my site) and configure for disambiguation if needed.
I'm not sure it's such a good idea to use the dotted module name
everywhere instead of the app label: it's handier to have the app
label.
>
> Imports are required for no other extensible feature of Django --
> while they are required to use derived app classes in your idea. I
> think that has a simple reason: it keeps the implementations separate
> and the settings clean of complex code. Something that is very helpful
> for users, I think.
>
Imports are bread and butter to Python applications, including Django,
and it seems a little doctrinaire to object to them just because
they're not used for everything. As I understand it, it's perfectly
good practice to use functions rather than function names in urlconfs.
Perhaps the core devs could pronounce on "imports considered harmful"
or someone could point me to such a pronouncement ...
>
> Somewhere in your site specific code (preferable app.py) you would
> create something this to override thing from 3rd party apps:
>
> from tagging.app import TaggingApp
> from django.utils.translation import gettext_lazy as _
>
> class MyTaggingApp(TaggingApp):
> db_prefix = 'my_tagging'
> verbose_name = _('my tagging')
> #..
>
> In your settings.py you would add:
>
> INSTALLED_APPS = (
> # ..
> 'tralala.app.MyTaggingApp',
> # ..
> )
>
Where does this site specific code live? I would like to put all my
code in reusable apps where possible, and site configuration code in
settings. Is this good practice, and if not what is the better
practice?
>
> from django.core.apps.base import App
> from django.utils.translation import gettext_lazy as _
>
> class MyAuthApp(App):
> app_label = 'tp_auth'
> verbose_name = _('my auth')
> module_name = 'third.party.app1.package.path.ends.in.auth'
>
> class MyCommentsApp(App)
> app_label = 'tp_comments'
> verbose_name = _('my comments')
> module_name = 'third.party.app2.package.path.ends.in.comments'
>
> Then in settings.py:
>
> INSTALLED_APPS = (
> # ..
> 'tralala.app.MyAuthApp',
> 'tralala.app.MyCommentsApp',
> # ..
> )
>
> The AppCache would get the models from the module_name in case it's
> provided.
>
OK, I see. Would the code defining MyAuthApp, MyCommentApp live in an
app? If not, then where? If so, which app? It's like defining
"recursion: see recursion" ;-)
Best 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
