Re: #16774 Backtracking URL resolver
Thank you charettes looking at my code and giving comments: https://github.com/meric/django/commit/2ef7d14040a261fe284a8b72490712d4019a5766#commitcomment-1847063 I have followed the comments and cleaned up the code: https://github.com/meric/django/commit/e118337293a480dfff08b9861c7045ac9fc893d5 On Thursday, September 13, 2012 12:01:38 PM UTC+10, meric wrote: > > Hi, > > I looked at https://code.djangoproject.com/ticket/16774 and decided to > implement the feature where views can raise urlresolvers.DoesNotResolve to > make URL Resolver to keep searching for a URL. > > The diff is here: https://github.com/meric/django/compare/ticket_16774 > > It introduces a new Exception class and adds a loop to the > BaseHandler.get_response. > > Can a committer or developer look at it? It's quite different to the > previous patch looked upon favourably by a core developer 10 months ago. > > Thanks, > Eric > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/HkjOoPzHbewJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.5 release plans
Can django support mongodb in version 1.5 ? , Jacob Kaplan-Moss wrote: Hi folks -- I wanted to fill everyone in on our plans for the Django 1.5 release. The highlights are: * Feature freeze October 1st, final out before Christmas. * One marquee feature of Django 1.5 is experimental Python 3 support. This is where we need your help the most: we need to be sure that our support for Python 3 hasn't destabilized Django on Python 2. We need lots of testing here! * Most features of 1.5 have already landed, but we're also hoping to land the new pluggable User model work, add support for PostGIS 2.0, start the process of deprecating django.contrib.localflavor, and a few other small things. * This'll be our first "master never closes" release: work, including new features, can continue to land on master while we ship the release. Please read on for details. Timeline Oct 1: Feature freeze, Django 1.5 alpha. Nov 1: Django 1.5 beta. Nov 26: Django 1.5 RC 1 Dec 10: Django 1.5 RC 2 Dec 17: Django 1.5 RC 3, if needed Dec 24 (or earlier): Django 1.5 final (All dates are "week of" - we'll do the releases that week, though not neccisarily that exact day.) Notice the longer-than-usual timeline from beta to final. We're doing this to provide some extra time stablizing the release after landing the Python 3 work. Please see below for details and how you can help. Python 3 support Django 1.5 includes experimental support for Python 3 (it's already landed on master). We're taking a "shared source" approach: Django's code is written in a way that runs on both Python 2 and Python 3 (without needing 2to3's translation). This means that we've touched nearly the entire codebase, and so the surface area for possible bugs is huge. WE REALLY NEED YOUR HELP testing out Django 1.5 *on Python 2*. Please grab master, or one of the upcoming alpha/beta/RC releases, and test it against your apps and sites. We need you to help us catch regressions. We're not yet recommending that people target Python 3 for deployment, so our main focus here is ensuring that we're still rock-solid on Python 2. If you *want* to give Python 3 a whirl things should be pretty solid, but we *especially* need real-world reports of success or failure on Python 2. Features in 1.5 --- Besides the stuff that's already landed (see https://docs.djangoproject.com/en/dev/releases/1.5/), there are a few other features we're hoping to land: * The "pluggable User model" work (Russell Keith-Magee). * Some early low-level schema alteration plumbing work (Andrew Godwin). * Moving django.contrib.localflavor out into individual external packages (Adrian Holovaty). * Support for PostGIS 2.0 (Justin Bronn). * Python 3 support in GeoDjango (Aymeric Augustin). * App-loading (Preston Holmes) is "on the bubble" - there's some debate among the core team over whether its ready, but it's close. Of course, as with our previous releases, the *real* list of what'll go in 1.5 is "whatever's done by October 1st". If you want to help with any of the above areas, contact the person doing the bulk of the work (listed above) and ask to help. And if you have other features you'd like to land, get 'em done! Master never closes --- This'll mark our first release where "master never closes". To recap: in previous releases, once we hit feature freeze we froze the development trunk, forcing all feature work out to branches. In practice, this meant months-long periods where new features couldn't be merged, and led to some stuff withering on the vine. That's not going to happen this time. Instead, when we release 1.5 alpha we'll make a 1.5 release branch right at that point. Work will continue on master -- features, bugfixes, whatever -- and the aplicable bugfixes will be cherry-picked out to the 1.5 release branch. The upshot is a bit more work for us committers -- we'll have to be sure to merge the aplicable commits over -- but no more "sorry you have to wait three months to merge this work." I'm very happy about this! [Committers: I'm happy to assist with this porting of bugfixes from master to the release branch.] See you on the other side, folks! 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Improve tutorial to use class based views
Hello, Like I, probably most people start with djagno by following the tutorial on the djangoproject.com website. This tutorial makes only use of function based views. But today we have this wonderful things called class based views. Is this really the best way to introduce newcomers to django ? Are there any plans to improve the docs to use class based views ? Regards, Jonas. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.5 release plans
On Wednesday, September 12, 2012 at 11:58 PM, timest wrote: > Can django support mongodb in version 1.5 ? If by supports you mean via the ORM, that's highly unlikely. Other then that there's nothing stopping you from using MongoDB within Django in any version of Django. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is there any plan to improve the performance of "render"?
Thanks for your reply. --Fuhong On Wednesday, September 12, 2012 4:35:37 PM UTC-4, Aymeric Augustin wrote: > > Le 12 sept. 2012 à 18:56, 富弘刘 > a écrit : > > I use django-debug-toolbar to analyze my website and noticed a lot of time > is consumed by template render. In my each page, I have about 10ms in > database queries, and about 100 ms in render. > > > > Hi Fuhong, > > Yes, the Django Template Language is known to be rather slow. > > Compiling it is a very hard problem, for two reasons: > - its scoping semantics don't match Python's (unlike Jinja2, for example); > - custom template tags can dynamically implement arbitrary behavior. > > The outcome of the latest attempt is documented here: > https://github.com/mitsuhiko/templatetk/blob/master/POST_MORTEM > > I'm not aware of more recent work on this topic. > > Best regards, > > -- > Aymeric. > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/rECx-N2JwDcJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is there any plan to improve the performance of "render"?
No, I have several 3rd party apps in my website and I haven't confirmed they are "thread safe". I'll check this later. Thanks:D On Wednesday, September 12, 2012 9:00:45 PM UTC-4, Karen Tracey wrote: > > On Wed, Sep 12, 2012 at 12:56 PM, 富弘刘 >wrote: > >> I use django-debug-toolbar to analyze my website and noticed a lot of >> time is consumed by template render. In my each page, I have about 10ms in >> database queries, and about 100 ms in render. > > > Have you tried using the cached template loader (see > https://docs.djangoproject.com/en/1.4/ref/templates/api/#loader-types)? > > Karen > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Sa4S8cYbqcYJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Improve tutorial to use class based views
Hi Jonas, The tutorial *does* cover class based generic views, but only towards the end: https://docs.djangoproject.com/en/dev/intro/tutorial04/#use-generic-views-less-code-is-better Starting with function based views, and then moving on to class based views by the end feels like the right approach, as it keeps things simple and obvious at the start, and gradually moves on to more complex abstractions. Regards, Tom On Thursday, 13 September 2012 12:14:03 UTC+1, jonas wrote: > > Hello, > > Like I, probably most people start with djagno by following the > tutorial on the djangoproject.com website. > This tutorial makes only use of function based views. > But today we have this wonderful things called class based views. > > Is this really the best way to introduce newcomers to django ? > > Are there any plans to improve the docs to use class based views ? > > Regards, > > Jonas. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/8U2lko-oIq4J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
list your group on djangonauts.org
As a followup to my lightning talk at DjangoCon, we've recently launched djangonauts.org a free listing of all Django-specific groups worldwide. If your group has a website, we'll link to it. If it doesn't, we will create a page that you can manage directly (the site is powered by DjangoCMS). Check it out. List your site. Spread the word. Follow @djangonauts_org. Brian Moloney -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/_IKr4MnUPkEJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Status of ticket #14087 - management commands in namespace packages
I'm curious if someone can shed some light on ticket #14087 (https://code.djangoproject.com/ticket/14087) It appears there is a pull request open on github to fix this issue (https://github.com/django/django/pull/178) This recently became a problem when we separated out a few apps into individual packages under the same namespace and there doesn't appear to be any sane way to monkeypatch around the issue. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/6RBbrue81eMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Testing django 1.5 with firebirdsql
Hi, I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on Ubuntu 11.04 with Python 2.7 I'm working right now on a new django-firebird [1] backend which do use the new python firebird driver (fdb) [2]. Then, I'm running the django test suite and I get an error when it try to create serializers_regress_ generice928. Seem like django is trying to create a table without fields, like this: 'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );' And this is not valid on Firebird. What does it trying to test here? Are there any way to avoid (or silence) this test ? Where is defined this model? Thanks in advance. --- Maxi [1] The old one use kinterbasdb [2] http://pypi.python.org/pypi/fdb/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/LLs-eM6Szv4J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Testing django 1.5 with firebirdsql
Hi Maxi, On Thu, Sep 13, 2012 at 8:20 PM, maxi wrote: > Hi, > > I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on > Ubuntu 11.04 with Python 2.7 > I'm working right now on a new django-firebird [1] backend which do use the > new python firebird driver (fdb) [2]. > > Then, I'm running the django test suite and I get an error when it try to > create serializers_regress_ > generice928. Seem like django is trying to create a table without fields, > like this: > > 'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );' > > And this is not valid on Firebird. > > What does it trying to test here? > Are there any way to avoid (or silence) this test ? > Where is defined this model? Hopefully the following leads will be of some help: As per the usual Dango policy for namign DB tables (i.e. prefixed by the app name and then the model name) it is clear the test app is serializers_regress. it its located in: tests/regression_tests/serializers_regress The Django test suite test apps are actually precisely that: Django apps. So something you can do is to transplant them to a pristine project (copying the app dir, adding it to INSTALLED_APPS, etc.). Once you have that you can perform any of the actions manage.py allows you to do with an app. With the advantage you have only that app and there is no noise from the massive Django test suite: For instance: * Running ./manage.py sql serializers_regress To see the DDL Django+your backend generates for the app models * Running ./manage.py test serializers_regress To run the tests, add -v2 to see the order in which the Django test machinery creates the model tables in the test DB. Now, looking at the 'GENERICE928' part of the table name, we have another hint, ist corresponds to a model whose name begins (case insensitively) with 'generic'. A quick perusing of serializers_regress.models shows there are a couple of them, and in particular there is this model:: class GenericIPAddressPKData(models.Model): data = models.GenericIPAddressField(primary_key=True) It has only one field, marked as the PK. Wild guess: Your backend's creation.py isn't generating the DB field corresponding to the (new in 1.4 IIRC) GenericIPAddressField field types i.e. is generating no DDL for it. And there is the origin of your no-fields-table DDL problem. HTH -- Ramiro Morales -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
