Problem while writing new backend support

[Ambrish Bhargava]

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 generated by Django is of "format" paramstyle. How can I get
queries in "qmark" paramstyle from Django?
2. Secondly I found that there are few queries in test suite which
contains LIMIT keyword. Now, my database does not supports LIMIT/
OFFSET keyword and because of this I am getting SQL ERROR. How can I
over come this problem?

Regards,
Ambrish Bhargava

--~--~-~--~~~---~--~~
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: Template-04's scope

[Malcolm Tredinnick]

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.
> 
> 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 up.
> 
> It seems most of the core team agrees -- it got 7 +0 votes. I think
> the only reason it failed to get any +1s is that it's just a big
> amount of work to review all at once. There's also the obvious
> question of weather we can pull off this refactoring without breaking
> backwards-compatibility.
> 
> I think the best thing to do with this is to take it to a branch so we
> can easily evaluate it against the trunk templates. If you're down for
> working on this off on a branch, I'm willing to help out and also
> review your code.

I agree with the mini-branch approach (particularly since Jacob's
volunteered to shepherd it). However, one thing I'm cautious about and
that I'd like to keep split out: a bunch of the bugs such as filtering
in ifequal tags, etc, can be fixed fairly simply and they're legitimate
bug fixes that can be applied to 1.0.X as well as trunk. So I've always
been thinking of this as a two-phase process: fixing most of the bugs
and then the refactoring separately. The first part can then easily be
applied to the 1.0.X branch as well.

Whether phase one is done on a branch or just a bunch of small patches
(and most of them will be relatively small) is a separate issue. If
Russell ever gets his recently announced +4 Fountain of Free Time
installed in his backyard, I'm flying out to Perth to have a drink from
it and then fix the bug portion, but right at the moment I'm not holding
my breath. My TODO list looks scary enough that if other people are
doing this, I'll just step back and kibitz.

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: Testing LDAP Backend

[Malcolm Tredinnick]

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 specific ldap server, I'd need to know what is in that server to make
> the tests work. Furthermore, I'd need to know where that server is to
> make it work.
> 
> I'd like an opinion on how to tackle this. I think that I should ship
> some info that one could slapadd into an empty ldap server, and require
> the test runner to put ldap settings in their test runner settings.py.
> 
> Is this too cumbersome for test runners? I really don't know how to make
> it easier.
> 
> How do I handle the case where someone tries to run the test, but they
> have supplied bad LDAP settings, or haven't added any data to ldap?

I think this is going to be a difficult situation. By default, no
testing can really happen, since it's a bit of a burden to require
people to have a running LDAP server (or have one installed that can be
started up) just for this particular auth method. But having some tests
in that backend that can be run would be useful.

I don't know enough what needs to be supplied to the backend, but could
you look for a setting that contained username/password for a user in
the LDAP backend. Presumably there's already some server settings that
are required to tell Django (including the tests) where to look? So
somebody wanting to test this will need to have access to an LDAP server
and know a username and password that can be used to test against it.

It would be disappointing if this sort of change required normal test
running to become more complicated. But I haven't seen you suggesting
that would be the case and I'm willing to say that the LDAP backend just
doesn't get tested in the normal run of things (and you and one or two
other people are going to have to commit to running it regularly and
keeping up with changes; maybe somebody can provide a buildbot slave
that also tests it).

Analogous case, by the way, is we don't automatically test the modpython
handler, since requiring the full Apache setup is a bit of unnecessary
overhead for the core tests. It'd be nice to have some "can be run
manually" tests for that, but that's pretty far down the pony request
list.

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: Dropping Python 2.3 compatibility for Django 1.1

[Julien Phalip]

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 -0.
>
> I don't have any particular love of or need for Python 2.3, but it has
> taken us a lot of effort to get and maintain Python 2.3 compatibility.
> I know maintaining this support is a pain, but in the grand scheme of
> things it doesn't bite us that often.
>
> 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
> release after a major 1.0 release is the right time to do it.
>
> Russ %-)

Maybe the best approach would be to warn people one or two releases in
advance. For example: "Python 2.3 support will be dropped in Django
1.3, so be warned and get ready for it."
--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Malcolm Tredinnick]

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.
> 
> I don't have any particular love of or need for Python 2.3, but it has
> taken us a lot of effort to get and maintain Python 2.3 compatibility.
> I know maintaining this support is a pain, but in the grand scheme of
> things it doesn't bite us that often.
> 
> 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
> release after a major 1.0 release is the right time to do it.

I'm not really feeling strongly one way or the other, although all the
people slobbering over "decorators" is not a reason to do it. Most of
the compatibility stuff is minor and doesn't interfere when you're not
using 2.3. It's not that hard to be 2.3-compatible when writing code
("oh, noes! I have to remember to do a three line thing to import sets
manually when writing a patch for django core that doesn't already use
it." Puh-leeze!)

The only reason I'd lean slightly towards dropping 2.3 is it will make
it more feasible to maintain a python 3.0 version in parallel. The
current unicode bug that requires us to wrap a lot of objects in
unicode() calls is only for 2.3 and really makes the 2to3 passage
painful, for example.

However, even saying Django 1.1 is the last 2.3-compatible version and
we drop it afterwards gives us a reasonable 3.0 support timeline, since
our timeframe doesn't really encourage any official 3.0 support for 1.1.

End of the day: I'm happy whichever way we go.

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: Dropping Python 2.3 compatibility for Django 1.1

[Jacob Kaplan-Moss]

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
> release after a major 1.0 release is the right time to do it.

Mostly it's the annoyance factor, but I think it goes a bit further
than "annoyance" -- there's a *lot* of places where we have to work
around 2.3 problems. It'd simplify quite a few nasty spots to be able
to factor 2.3 out.

The reason we have to do it at *some* time is it's really the first
step towards Python 3.0 compatibility. We really won't be able to go
2.3+ ---> 3.0 all the way in one fell swoop, so we'll need to work up
to it. In my experiments it seemed that going 2.5 -> 3.0 is pretty
painless (the work Martin van Lowis did can be adapted easily to
support both 2.5, 2.6, and 3.0, but not earlier). So we need to start
down the road of deprecating older versions in preparation for an
eventual move to 3.0.

Of course, we're talking a timeline measured in years here, but the
road start now.

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: Dropping Python 2.3 compatibility for Django 1.1

[Russell Keith-Magee]

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 us a lot of effort to get and maintain Python 2.3 compatibility.
I know maintaining this support is a pain, but in the grand scheme of
things it doesn't bite us that often.

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
release after a major 1.0 release is the right time to do it.

Russ %-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

One suggest for a new Lorem Ipsum

[Diego Andrés Sanabria Martin (diegueus9)]

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

http://www.el-directorio.org/Diegueus9
El sitio de linux y el Software Libre en Colombia

"Hay pecados cuya fascinación está más en el recuerdo que en la
comisión de ellos." Oscar Wilde

--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[zvoase]

+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 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: Template-04's scope

[Johannes Dollinger]

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 tricky to do in a backwards-compatible way:
>> we've sorta pasted ourselves into a corner here by letting tags do
>> anything they want in terms of parsing. This lead to an inconsistency
>> in syntax that we (unfortunately) have to continue to support.
>>
>> However, that's no reason not to have a better API on top that
>> third-party tags can use -- as long as internal tags don't break.
>>
> Heretical suggestion: {: :}, {! !}, {$ $} or {[ ]} with a different
> processor (falling back to the original if necessary), and therefore  
> no
> need for a fully backwards-compatible approach?

That hopefully won't be necessary. However, the possibility to  
configure those token boundaries at runtime might be a nice feature. I  
missed it for LaTeX templates.


--~--~-~--~~~---~--~~
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: Template-04's scope

[Johannes Dollinger]

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 up.
>
> It seems most of the core team agrees -- it got 7 +0 votes. I think
> the only reason it failed to get any +1s is that it's just a big
> amount of work to review all at once. There's also the obvious
> question of weather we can pull off this refactoring without breaking
> backwards-compatibility.

I'm glad you like it, more on backwards-compatibility below.

> I think the best thing to do with this is to take it to a branch so we
> can easily evaluate it against the trunk templates. If you're down for
> working on this off on a branch, I'm willing to help out and also
> review your code.
>
>> * The code shuffling is purely cosmetic, it just feels wrong to stuff
>> everthing in __init__.py. It's already too big for my taste. And I
>> honestly don't know how to cleanly split shuffling and functionality
>> in separate patches.
>
> Yeah, this is the big reason a branch would be better -- we can
> separate the big deck-chair-shuffling from the refactoring and be able
> to review better.
>
>> * 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 sorta pasted ourselves into a corner here by letting tags do
> anything they want in terms of parsing. This lead to an inconsistency
> in syntax that we (unfortunately) have to continue to support.
>
> However, that's no reason not to have a better API on top that
> third-party tags can use -- as long as internal tags don't break.

That should be entirely possible, using either an additional decorator  
for parser functions [EMAIL PROTECTED] or [EMAIL PROTECTED]($new_api=True)`, or 
 
a new method [EMAIL PROTECTED] (for some reasonable value of  
$new_api).
It might even be possible to fold `TokenStream` into `Token`, but that  
would introduce state in `Token` - haven't thought this through.

The refactored version of defaulttags currently passes most tests with  
the following exceptions
* {% if not not %} raises TemplateSyntaxError (fixable, but I'm not  
shure it's worth it)
* integer literals with a trailing colon raise TemplateSyntaxError
* whitespace is insignificant, therefore {{ foo | filter }} passes.

The only real bc problem were unquoted unicode viewnames in {% url %}.  
That's fixed in my latest patch at the expense of regexp beauty.
The current version accepts a quoted string as well, so one could  
deprecate unquoted viewnames and fix that in 2.x.
That's been rejected in 
http://groups.google.com/group/django-developers/browse_thread/thread/fd30cb20f80c6c79
 
.

> So: what do you say we make a template-cleanup branch and start
> working on this over there?

If it has to be a branch, so be it. I entered myself as implementor  
into the feature table.




--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Antoni Aloy]

+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

--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Justin Bronn]

+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 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: Dropping Python 2.3 compatibility for Django 1.1

[Tim Chase]

> 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, decorators, generators, and built-in sets!

-tim




--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Jannis Leidel]

> 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 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: Template-04's scope

[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 tricky to do in a backwards-compatible way:
> we've sorta pasted ourselves into a corner here by letting tags do
> anything they want in terms of parsing. This lead to an inconsistency
> in syntax that we (unfortunately) have to continue to support.
>
> However, that's no reason not to have a better API on top that
> third-party tags can use -- as long as internal tags don't break.
>   
Heretical suggestion: {: :}, {! !}, {$ $} or {[ ]} with a different
processor (falling back to the original if necessary), and therefore no
need for a fully backwards-compatible approach?

regards
 Steve


--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Ned Batchelder]

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 putting off being able to use 2.4 syntax.  The only reason to take 
this path is if the devs want to be conservative and get a real data 
point before completely moving away from 2.3.

--Ned.
http://nedbatchelder.com

[EMAIL PROTECTED] wrote:
> 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, argument against is that some people don't
> have access to it, the only question is that a sizeable portion of
> Django users).
>
> alex
>
> On Nov 25, 12:33 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>   
>> 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
>> 
> >
>
>   

-- 
Ned Batchelder, http://nedbatchelder.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: Dropping Python 2.3 compatibility for Django 1.1

[Horst Gutmann]

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 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 them or they
> can hang out in 1.0 land until they are able to upgrade. Remember
> PyCon 2008? :)
>
> --
> Brian Rosner
> http://oebfare.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: Dropping Python 2.3 compatibility for Django 1.1

[Brian Rosner]

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 them or they
can hang out in 1.0 land until they are able to upgrade. Remember
PyCon 2008? :)

-- 
Brian Rosner
http://oebfare.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
-~--~~~~--~~--~--~---

Testing LDAP Backend

[Jeff Anderson]

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 tests work. Furthermore, I'd need to know where that server is to
make it work.

I'd like an opinion on how to tackle this. I think that I should ship
some info that one could slapadd into an empty ldap server, and require
the test runner to put ldap settings in their test runner settings.py.

Is this too cumbersome for test runners? I really don't know how to make
it easier.

How do I handle the case where someone tries to run the test, but they
have supplied bad LDAP settings, or haven't added any data to ldap?

Thanks for any insight!


Jeff Anderson

http://code.djangoproject.com/ticket/2507



signature.asc
Description: OpenPGP digital signature

Re: Dropping Python 2.3 compatibility for Django 1.1

[[EMAIL PROTECTED]]

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, argument against is that some people don't
have access to it, the only question is that a sizeable portion of
Django users).

alex

On Nov 25, 12:33 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> 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
--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[Ivan Sagalaev]

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

--~--~-~--~~~---~--~~
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: Dropping Python 2.3 compatibility for Django 1.1

[J. Cliff Dyer]

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 contrib.gis called for Python 2.4,
which actually helped push us to RHEL 5.

I also think it's a better situation abandoning Py 2.3 people at django
1.0.x rather than at 0.96.x.

+0.  I'm okay with it.

Cheers,
Cliff

 
On Tue, 2008-11-25 at 11:08 -0600, Jacob Kaplan-Moss wrote:
> 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 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: Dropping Python 2.3 compatibility for Django 1.1

[Ludvig Ericson]

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 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: Denormalisation Magic, Round Two

[Christian Schilling]

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 @denormalized decorator a drop-in
replacement for pythons @property
decorator. and the function becomes much shorter and easier to
understand.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Dropping Python 2.3 compatibility for Django 1.1

[Jacob Kaplan-Moss]

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 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: Final(ish) 1.1 feature list

[Marty Alchin]

Thanks, guys. All that just to delete a question mark from my name
after signed cookies. :)

-Gul

On Tue, Nov 25, 2008 at 12:04 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> 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 
"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: Final(ish) 1.1 feature list

[Jacob Kaplan-Moss]

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 
"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: Final(ish) 1.1 feature list

[alex.gay...@gmail.com]

Ok, the page is now editable.

On Nov 25, 11:57 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> *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:
> > On Tue, Nov 25, 2008 at 10:34 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> >> 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 it opened up for the rest of us?
>
> > If you log in, you can get an edit button at the bottom.
> >  (Or at least, I could.)
>
>
>
>  forbidden.png
> 33KViewDownload
--~--~-~--~~~---~--~~
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: Final(ish) 1.1 feature list

[Marty Alchin]

*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:
> On Tue, Nov 25, 2008 at 10:34 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>>
>> 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 it opened up for the rest of us?
>
> If you log in, you can get an edit button at the bottom.
>  (Or at least, I could.)
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

<>

meta: (minor) simple text editor setting conventions?

[Ramiro Morales]

Hi,

[This could probably be considered bikeshedding by some, hopefully it
doesn't.]

I would like to to propose a simple convention/guidelines for people
having commit-access for the Python source code files:

* Stripping non-significant white space from the end of lines.
* Ending every non-zero-byte-size file with a carriage return.

for files going into the repository.

There are several files right now that don't comply with these
conventions and I'm not proposing to change all of them at the same time
or something similar, that would signify a disruption of the history of
the project, also I don't think implementing something like repository
hooks to enforce a policy is necessary either.

But if some kind of such guidelines were to be adopted, the next time
one of thse files is modified (as part of the normal project evolution)
with a text editor configured accordingly, it would be converted to the
'right' format. So, a gradual convergence to a predictable style would be
achieved.

This wouldn't need to be a requirement for patch submitters, but just
the fact that such a patch gets applied and edited in some way by a core
committer during its review would also convert them. I suspect this
would help to get less 'noisy' patches (because I also suspect the
formatting conventions are widespreadly used) and it would also allow us
to to workaround the known limitation of our version of Trac that
borks the HTML display of patches containing:

"\ No newline at end of file".

Most modern text editor support the relevant settings with the
possibility of activating them for specific filename extensions.

If this proposal is adopted I could submitting a patch for
internals/contributing.txt to document it if deemed necessary.

Regards,

--
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Final(ish) 1.1 feature list

[Jeremy Dunck]

On Tue, Nov 25, 2008 at 10:34 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> 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 it opened up for the rest of us?

If you log in, you can get an edit button at the bottom.
  (Or at least, I could.)

--~--~-~--~~~---~--~~
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: Ticket 8638: Provide setting to disable e-mail sending

[Luke Plant]

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.
>
> Firstly, the title simply says it wants the ability to disable
> emails, while some of the comments on the ticket are looking for a
> bit more than simply disabling.  Where would we like to take this?

I added a comment on the bug - in summary, why does this need to be 
part of Django at all?  I use fakemail [1], and it already does 
almost everything you suggested.  The only thing it doesn't do is 
automatically override the settings, but every (sensible) user will 
be using different settings for their dev box (for their database at 
the very least), so I don't think we need to be that bothered about 
users who haven't set up a settings file for their dev box.

I'm -1 on adding much functionality here unless there is some real 
value -- it is just duplicating what is available elsewhere, and adds 
to the maintainance burden of Django.

Regards,

Luke

[1] http://www.lastcraft.com/fakemail.php

-- 
"Mediocrity: It takes a lot less time, and most people don't realise 
until it's too late." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: Final(ish) 1.1 feature list

[Marty Alchin]

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 it opened up for the rest of us?

-Gul

--~--~-~--~~~---~--~~
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: Template-04's scope

[Jacob Kaplan-Moss]

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 --
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 up.

It seems most of the core team agrees -- it got 7 +0 votes. I think
the only reason it failed to get any +1s is that it's just a big
amount of work to review all at once. There's also the obvious
question of weather we can pull off this refactoring without breaking
backwards-compatibility.

I think the best thing to do with this is to take it to a branch so we
can easily evaluate it against the trunk templates. If you're down for
working on this off on a branch, I'm willing to help out and also
review your code.

> * The code shuffling is purely cosmetic, it just feels wrong to stuff
> everthing in __init__.py. It's already too big for my taste. And I
> honestly don't know how to cleanly split shuffling and functionality
> in separate patches.

Yeah, this is the big reason a branch would be better -- we can
separate the big deck-chair-shuffling from the refactoring and be able
to review better.

> * 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 sorta pasted ourselves into a corner here by letting tags do
anything they want in terms of parsing. This lead to an inconsistency
in syntax that we (unfortunately) have to continue to support.

However, that's no reason not to have a better API on top that
third-party tags can use -- as long as internal tags don't break.

So: what do you say we make a template-cleanup branch and start
working on this over 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
-~--~~~~--~~--~--~---

Template-04's scope

[Johannes Dollinger]

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 too big for my taste. And I  
honestly don't know how to cleanly split shuffling and functionality  
in separate patches.

* I always felt the API for custom tags is too verbose. There's almost  
no abstraction which makes parsing something like {% url %}  
unnecessarily hard - even django's builtin parser doesn't get it right  
(split(' ') and split(',')). Yes, that could be seen as a feature  
request. But builtin tags would also benefit from abstraction. Just  
comparing code length (compactness is desirable, although by no means  
the only quality measure): #7806's defaulttags contains 20% less LOC  
(not counting blank lines, comments, and docstrings).

* The bugs, obviously. As Malcolm pointed out, most are symptoms of  
the same underlying problems.

Anyway, here's a list of the tickets I tried to fix in #7806 (although  
some of them were merely side effects):

Bugs


#5756: Any template tag that uses Variable instead of  
parser.compile_filter does not handle filters.
http://code.djangoproject.com/ticket/5756

#5862: Filters are not applied in an include tag
Wontfixed, but it's really an instance of #5756.
http://code.djangoproject.com/ticket/5862

#5971: django.template.TokenParser inconsistent with parsing filters
http://code.djangoproject.com/ticket/5971

#6271: filter arguments with spaces break several template tags
http://code.djangoproject.com/ticket/6271

#6296: ifequal, filter and hardcoded-string doesn't work
http://code.djangoproject.com/ticket/5756

#6510: get_nodes_by_type refactor for easier extensibility (fixes an  
underlying bug for IfEqualNode)
http://code.djangoproject.com/ticket/6510

#6535: parser.compile_filter() does not support negative numbers
http://code.djangoproject.com/ticket/6535

#7295: quotes, escaping and translation of string literals handled  
inconsistently in templates
http://code.djangoproject.com/ticket/7295

#7377: "extends" and "block" tags are not available when constructing  
template from scratch
http://code.djangoproject.com/ticket/7377

#9315: Keyword arguments with spaces and the url tag
http://code.djangoproject.com/ticket/9315


Features
===

#4746: Allow whitespace before and after filter separator
The patch goes further: whitespace is insignificant anywhere between  
tokens. That means
`{% url view foo , kw = bar | filter : arg %}`
would be valid.
http://code.djangoproject.com/ticket/4746


Threads
===
There are a couple more I'm aware of and probably and probably dozens  
I haven't found yet - as a starting point:
http://groups.google.com/group/django-developers/browse_thread/thread/4f5b01719e497325
http://groups.google.com/group/django-developers/browse_thread/thread/ba0644b835e3ec40
http://groups.google.com/group/django-developers/browse_thread/thread/c90b6e29d20724ca

Related to the code shuffling in #7806 (although my intention was  
merely readability):
http://groups.google.com/group/django-developers/browse_thread/thread/35aae0e8da804bd9






--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Final(ish) 1.1 feature list

[Jacob Kaplan-Moss]

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
features.  I fairly arbitrary assigned committers to features they
voted +1 on, but please feel free to remove yourself or switch around
or whathaveyou if I messed it up.

I've listed a few implementors where it was obvious, but in general I
need folks who want to work on feature to "claim" 'em on the wiki
page. That way we know who do bug when things don't get done :)

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
-~--~~~~--~~--~--~---

Generic views and select_template

[Michel Thadeu Sabchuk]

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 friends, I think you got the idea...

My view looks like this:

def forum_detail(request, object_id):
object = get_object_or_404(...)
queryset = object.queryset...
return object_list(request, queryset,
template_name='sometemplate.html', extra_context={'object':object})

Now I trying to use the select_template function to choose a template
to object_list. I see that render_to_string accepts a tuple as
template_name, this way it passes this tuple by select_template
reather than get_template. The render_to_response shortcuts uses
render_to_string and select_template too.

The generic views do not use select_template, it use get_template. Why
about change it to use select_template as render_to_response? I can
send a patch if you enjoy the idea...

Best regards!
--~--~-~--~~~---~--~~
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: patch review wanted (ticket #9433)

[rndblnch]

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 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: Denormalisation Magic, Round Two

[Andrew Godwin]

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 'efficient updates'
(where, say, only half of a model's instances are affected by the change
that just occurred) but I now see it's the function's job to do that.

I quite like this solution, it's rather clean; my own solution is far
more lengthly, and while some of that is the efficiency code I
previously mentioned, I can't help but think I have some redundancy in
there now...

I've published my code at http://code.google.com/p/django-denorm/, and
I'll 'release' it soonish, but I'm liking this decorator approach more
and more, especially as we can then just build 'AggregateFields' on top
of them.

Andrew

--~--~-~--~~~---~--~~
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: Using pysqlite2 instead of sqlite3 when desired

[oggie rob]

> 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
> it. I don't see the functionality request as being controversial and I'm
> probably putting too much effort into worrying about the fine details.

I've faced issues with sqlite3 before and the biggest issue in my case
was simply being aware that using pysqlite was a quick and simple
solution to concurrency and db locking issues. So making it explicit
wouldn't hurt, for the sole reason that it communicates that concept
(assuming of course it is documented :)

Since sqlite takes advantage of the DATABASE_OPTIONS field for
timeout, it would probably make sense to use # 2.

 -rob
--~--~-~--~~~---~--~~
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: Proposal: Decoupling authorization from view

[Thomas Guettler]

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".
>
>   
Hi Eric,

I am very happy that someone understood what I want.

> Perhaps you could post your code somewhere so that 3rd-party app
> developers can standardize their authorization (git-hub?).
>
>   
I added a snippet:
http://www.djangosnippets.org/snippets/1214/

  Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---