Problem while writing new backend support

Hi, I am trying to develop new backend support for Django. I ran "python manage.py test" command to execute test. Now I am facing following problem: 1. Python Database API Specification v2.0 implementation that I am using, supports "qmark" paramstyle. But it seems that the query that got

Re: Template-04's scope

On Tue, 2008-11-25 at 10:28 -0600, Jacob Kaplan-Moss wrote: > On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger > <[EMAIL PROTECTED]> wrote: > > I'm aware that #7806 propably does too much at once. I'd like to hear > > what's in scope for 1.1 and what you believe doesn't belong in django. >

Re: Testing LDAP Backend

On Tue, 2008-11-25 at 10:52 -0700, Jeff Anderson wrote: > Hello, > > I'm trying to figure out how to write tests for ticket #2507, which is > the LDAP auth backend. I find it difficult to create repeatable tests > across different "supported" ldap servers. If I were to write tests for > a

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > Hi folks -- > > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > I'm going to be the stick in the mud and say

Re: Dropping Python 2.3 compatibility for Django 1.1

On Wed, 2008-11-26 at 09:43 +0900, Russell Keith-Magee wrote: > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: > > > > Hi folks -- > > > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > I'm going to be the stick in the mud and say -0.

Re: Dropping Python 2.3 compatibility for Django 1.1

On Tue, Nov 25, 2008 at 6:43 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > I know the GIS stuff is bound to 2.4+, but other than this, is there > any particularly compelling reason to drop 2.3 support other than the > annoyance factor for 1.1? I'm just not convinced that the first minor >

Re: Dropping Python 2.3 compatibility for Django 1.1

On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Hi folks -- > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. I'm going to be the stick in the mud and say -0. I don't have any particular love of or need for Python 2.3, but it has taken

One suggest for a new Lorem Ipsum

Hi, In Django in somwhere is a tag Lorem Ipsum, i suggest to use Lorem Ipsum 2 http://lorem2.com/ -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital blog trágico mágico cómico musical: http://diegueus9.blogspot.com blog geek: http://pyautoservicio.blogspot.com cel 3015290609

Re: Dropping Python 2.3 compatibility for Django 1.1

+1 For me, too. If people want to use the cutting-edge Django release then they can at least update Python to 2.4 (which is now 4 years old anyway). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: Template-04's scope

Am 25.11.2008 um 19:45 schrieb Steve Holden: > > Jacob Kaplan-Moss wrote: >> On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger >> [...] >>> * I always felt the API for custom tags is too verbose. >>> >> >> There's almost universal agreement on this point :) >> >> It's unfortunately pretty

Re: Template-04's scope

Am 25.11.2008 um 17:28 schrieb Jacob Kaplan-Moss: > I'm actually pretty happy with the general idea you've taken here -- > django.template needs some cleanup, and a holistic approach that > addresses the multiple issues at once is going to produce better code > than multiple patches all stacked

Re: Dropping Python 2.3 compatibility for Django 1.1

+1 for me too 2.4 is still quite conservative :) The actual Django stable version is good enought to let people developing in until the decide/can move to a new version -- Antoni Aloy López Blog: http://trespams.com Site: http://apsl.net --~--~-~--~~~---~--~~

Re: Dropping Python 2.3 compatibility for Django 1.1

+1. Eliminates a ton of compatibility code, e.g., no more carrying around a three thousand line Decimal implementation. -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to

Re: Dropping Python 2.3 compatibility for Django 1.1

> I'd like to officially drop Python 2.3 support in Django 1.1. > Discuss. +0.5 (not withstanding any panic'ed folks saying "I need 2.3!", consider it a +1) I think Debian Stable has moved to 2.4. All the servers that I touch currently with 2.3 on them now also have 2.4 on them. Yay,

Re: Dropping Python 2.3 compatibility for Django 1.1

> I'd like to officially drop Python 2.3 support in Django 1.1. +1, every single reason that has been stated convinces me of dropping support for 2.3. Cheers, Jannis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: Template-04's scope

Jacob Kaplan-Moss wrote: > On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger > [...] >> * I always felt the API for custom tags is too verbose. >> > > There's almost universal agreement on this point :) > > It's unfortunately pretty tricky to do in a backwards-compatible way: > we've

Re: Dropping Python 2.3 compatibility for Django 1.1

One way to collect feedback would be to make one small change to the code that would require 2.4, and ship 1.1 that way. Then we'd hear from people who really couldn't run 1.1, but we haven't made too large a change yet, so if we wanted to re-enable them we could. I realize this means

Re: Dropping Python 2.3 compatibility for Django 1.1

Big +1 from me. Finally real decorators, generators and not to forget sets as built-in type :D -- Horst On Tue, Nov 25, 2008 at 7:04 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 25, 2008 at 10:08 AM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: >> >> Hi folks -- >> >> I'd like

Re: Dropping Python 2.3 compatibility for Django 1.1

On Tue, Nov 25, 2008 at 10:08 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > Hi folks -- > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. +1. This needs to happen. Python 2.3 is getting pretty old and I would imagine that most people have at least 2.4 available to

Testing LDAP Backend

Hello, I'm trying to figure out how to write tests for ticket #2507, which is the LDAP auth backend. I find it difficult to create repeatable tests across different "supported" ldap servers. If I were to write tests for a specific ldap server, I'd need to know what is in that server to make the

Re: Dropping Python 2.3 compatibility for Django 1.1

Sounds double plus good(+1) from me. That being said, it's been said before that Djagno-dev, even if 20 people are vocally in favor of something, is a tiny fraction of all the people using Django, is there perhaps a better/more objective way of collecting feedback(the obviously, perhaps only,

Re: Dropping Python 2.3 compatibility for Django 1.1

Ludvig Ericson wrote: > On Nov 25, 2008, at 18:08, Jacob Kaplan-Moss wrote: >> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > Oh god please, YES! Gimme my decorator syntax sugar, oh yeah. ... and generator expressions, too! +1

Re: Dropping Python 2.3 compatibility for Django 1.1

I was hesitant on this when I heard rumblings of it around 1.0, but my workplace is finally getting off RHEL 4, which had Py 2.3, so I no longer have an issue with dropping 2.3 support. RHEL 5 is at 2.4. Are other places are still stuck with RHEL 4? Even before, the install notes for

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 25, 2008, at 18:08, Jacob Kaplan-Moss wrote: > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. Oh god please, YES! Gimme my decorator syntax sugar, oh yeah. - Ludvig. --~--~-~--~~~---~--~~ You received this message because you are

Re: Denormalisation Magic, Round Two

i spend some time implementing my idea above (still just a proof of concept, all testing i did was on the example project) the resulting models.py: (still in the same place) http://github.com/initcrash/django-denorm/tree/master/example%2Fgallery%2Fmodels.py as you can see, this makes the

Dropping Python 2.3 compatibility for Django 1.1

Hi folks -- I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Final(ish) 1.1 feature list

On Tue, Nov 25, 2008 at 11:02 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ok, the page is now editable. Yeah, that's my bad. Thanks for fixing it, Alex. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: Final(ish) 1.1 feature list

*sigh* I was afraid someone would say that. I didn't think I had to state that I was indeed logged in at the time. Perhaps you have WIKI_ADMIN priveleges? :) I can edit other articles on the wiki, just not that one. -Gul On Tue, Nov 25, 2008 at 11:49 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: >

Re: Ticket 8638: Provide setting to disable e-mail sending

On Tuesday 25 November 2008 01:02:03 Rob Hudson wrote: > Hi Django Devs, > > I saw that ticket[1] made it into the 1.1 list and I was drawn to > it. I have a project that will be doing some mass sending of emails > soon, so I could definitely use something more than what is > currently there. > >

Re: Final(ish) 1.1 feature list

The biggest issue is that we can't edit anything. There's no "Edit Page" button, and when I manually add "?action=edit" to the URL, it gives me an editor form, but upon submission, I see the culprit: 403 Forbidden (WIKI_ADMIN privileges are required to perform this operation). Any hope of getting

Re: Template-04's scope

On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > I'm aware that #7806 propably does too much at once. I'd like to hear > what's in scope for 1.1 and what you believe doesn't belong in django. I'm actually pretty happy with the general idea you've taken here --

Template-04's scope

I'm aware that #7806 propably does too much at once. I'd like to hear what's in scope for 1.1 and what you believe doesn't belong in django. Why the patch still does that/too much: * The code shuffling is purely cosmetic, it just feels wrong to stuff everthing in __init__.py. It's already

Final(ish) 1.1 feature list

Hi folks -- I've updated the 1.1 feature list (http://code.djangoproject.com/wiki/Version1.1Features) with the discussion from the draft. If I've missed anything let me know, or if it's an obvious error just fix the page. The bug thing we need now is to determine who's going to work on which

Generic views and select_template

Hi guys, I try to use generic views whenever possible in my projects. Sometimes, the generic view isn't sufficient to me, then I write a view that returns a generic view. The common case is a detail page with a list of objects related to it. This page can be a forum and his posts, a user and his

Re: patch review wanted (ticket #9433)

i've just proposed a new approach to solve this bug at the ticket page . the idea is to just add to django the hooks that make it possible to fix the bug from the outside. renaud --~--~-~--~~~---~--~~ You received this

Re: Denormalisation Magic, Round Two

Christian Schilling wrote: > i don't think so. > if you mean lines 35-38 in fields.py: > this is only used to rebuild all denormalized values in the whole DB > via the management command, witch means everything needs to be updated. > Ah yes, ignore me. I was trying to see how you did

Re: Using pysqlite2 instead of sqlite3 when desired

> Since so far only you and I have made real input here, I'd like to hear > what any of the other maintainers (or anybody else who uses this stuff) > thinks. Realistically, any of the options are survivable, so barring any > great arguments one way or the other, we should just pick one and commit

Re: Proposal: Decoupling authorization from view

Eric Drechsel schrieb: > Hi Thomas, > > Ya, it would be really nice if there was a standard way of handling > authorization for views, so that external code can check if a view is > authorized. I have been doing identically the same thing, except I was > naming the view attribute "authorized". >