Re: Speeding up test running

[Russell Keith-Magee]

On Fri, Jan 15, 2010 at 9:59 AM, Vitaly Babiy  wrote:
> I have also been thinking about this, I think there is one problem but I am
> not sure. This is when you have functional test and they need talk to a
> database. In most cases you will be using transactions which should be fine,
> but if for some reason you can't use transaction for test this will have to
> run each one on its own.

The other way to skin this particular cat is to have multiple test
databases, one for each thread. This approach would require a lot more
modifications to the existing test framework (to set up and allocate
individual tests/test cases to each database), but it would guarantee
that threads didn't end up with contention or corruption over a single
database.

Yours,
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: help needed: non-relational DB support

[Russell Keith-Magee]

On Fri, Jan 15, 2010 at 5:08 AM, Waldemar Kornewald
 wrote:
> On Thu, Jan 14, 2010 at 2:42 PM, Russell Keith-Magee
>  wrote:
>> Speaking for myself, I'm pretty busy trying to get features completed
>> before the 1.2 feature deadline. At the moment, anything that isn't on
>> the 1.2 roadmap is only getting cursory attention from me. I suspect
>> the same is true of most of the other core developers, and anyone else
>> that is closely involved in the Django development process.
>
> Do you think you can work with us in the 1.3 release cycle? In the
> meantime we can try to back-port SQL as far as possible.

I haven't decided what I want to work on in the 1.3 release cycle. I'd
certainly like to see support for non-SQL backends, but there are many
other features I'd like to work on, too. I'm not going to make any
firm decisions until the 1.3 feature discussion process comes around.
At that time, I'll evaluate the proposals that are on the table.

So - to that end - the most productive thing you can do is get a solid
proposal together. That means a clear statement of the changes you
want to make to the Django core, and why those changes are required.
In the case of non-SQL backends, you will also need to demonstrate
that the changes you are proposing aren't GAE specific - that you are
proposing changes that are sufficient to encompass the general problem
of non-SQL backends.

And to be clear - a solid proposal isn't just "merge this branch". A
patch/branch is one way to prove that you have thought about the
problem in detail, but you also need to provide the discussion and
description necessary to explain the nature of and reasoning behind
the changes you want to make.

The proposal doesn't need to be complete on the first pass, either.
Even demonstrating that you have a solid grasp of the size and scope
of the problems that need to be solved may be sufficient.

You don't have to develop your proposal in a vacuum, either. If you
need feedback or design guidance, just ask. But please be considerate
of the fact that yours isn't the only proposal, and there are other
schedule pressures that exist.

> We really
> need to get this into 1.3 and some support from the Django core team
> would be great.

Well... you're not going to get anything into 1.3 without core team support :-)

I would also advise that you moderate your expectations. Saying that
you "really need to get this into 1.3" implies that you are making
plans based on the assumption that non-SQL backend support will be
merged into trunk and available in 1.3.

This is not a wise course of action. Nothing is final until it is
actually in trunk. There's no guarantee that non-SQL support will be
selected as a 1.3 feature. Even if non-SQL backends are picked as a
1.3 feature, that doesn't guarantee that 1.3 will include non-SQL
backend support - if the code isn't ready, the feature will be bumped.
Our schedule determines the feature set, not the other way around.

Yours
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Speeding up test running

[Alex Gaynor]

On Thu, Jan 14, 2010 at 7:59 PM, Vitaly Babiy  wrote:
> I have also been thinking about this, I think there is one problem but I am
> not sure. This is when you have functional test and they need talk to a
> database. In most cases you will be using transactions which should be fine,
> but if for some reason you can't use transaction for test this will have to
> run each one on its own.
> Vitaly Babiy
>
>
> On Thu, Jan 14, 2010 at 4:16 PM, ptone  wrote:
>>
>> This is probably just a curiosity, but I was playing with ways to test
>> the raw power of my new 8-core mac pro and was looking at how to apply
>> this to testing.
>>
>> By using multiprocessing I was able to reduce the running of the
>> current trunk tests from 6 minutes to 3.
>>
>> Because a test case needs to be pickled to be pushed to the worker
>> pool and not all test cases could be, almost 2 minutes of this is
>> spent having to run just several tests in the main thread.  If this
>> was resolved, I think the whole test suite could be run in about a
>> minute.
>>
>> When it hits a stretch of tests that can be dispatched and lights up
>> all cores, it just screams.
>>
>> With the increase of multicore machines, perhaps this is something of
>> interest.  Even with fast fail - waiting for tests to run takes away
>> from other development tasks, and being able to run the test suite
>> more frequently would probably help catch some bugs earlier before
>> they cascade or propagate by being extended or referred to.  I'll
>> grant this is a relatively low priority - but if anyone wants, I'd be
>> happy to clean up my hack and post it as a gist.
>>
>> -Preston
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

ISTM that if the only issue is knowing whether a test is isolated by a
transaction that's an easy problem to solve, we already have a way of
knowing that, the class of test itself!

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Speeding up test running

[Vitaly Babiy]

I have also been thinking about this, I think there is one problem but I am
not sure. This is when you have functional test and they need talk to a
database. In most cases you will be using transactions which should be fine,
but if for some reason you can't use transaction for test this will have to
run each one on its own.

Vitaly Babiy


On Thu, Jan 14, 2010 at 4:16 PM, ptone  wrote:

> This is probably just a curiosity, but I was playing with ways to test
> the raw power of my new 8-core mac pro and was looking at how to apply
> this to testing.
>
> By using multiprocessing I was able to reduce the running of the
> current trunk tests from 6 minutes to 3.
>
> Because a test case needs to be pickled to be pushed to the worker
> pool and not all test cases could be, almost 2 minutes of this is
> spent having to run just several tests in the main thread.  If this
> was resolved, I think the whole test suite could be run in about a
> minute.
>
> When it hits a stretch of tests that can be dispatched and lights up
> all cores, it just screams.
>
> With the increase of multicore machines, perhaps this is something of
> interest.  Even with fast fail - waiting for tests to run takes away
> from other development tasks, and being able to run the test suite
> more frequently would probably help catch some bugs earlier before
> they cascade or propagate by being extended or referred to.  I'll
> grant this is a relatively low priority - but if anyone wants, I'd be
> happy to clean up my hack and post it as a gist.
>
> -Preston
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, 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: phone2numeric doesn't convert "Q" or "Z"

[Gabriel Hurley]

I've opened a ticket and submitted a patch that fixes this strange
oversight: http://code.djangoproject.com/ticket/12613

Thanks!
- Gabriel

On Jan 14, 5:05 am, Harro  wrote:
> hmm that's indeed weird. The regex excludes those as well
> specifically.
> The Q and Z should be added or a comment should be added to the code
> explaining the reason for leaving them out.
>
> On Jan 14, 11:23 am, Gabriel Hurley  wrote:
>
>
>
> > 1. Is there a reason Django's phone2numeric method doesn't work for
> > the letters Q or Z? I realize that those two letters are the ones that
> > share four letters to a number instead of the standard three, but
> > that's no reason to leave them out. Most modern phones include the
> > full alphabet on their keys and it's silly not to let people convert
> > those two letters.
>
> > If there's no reason, I'd be happy to submit a patch since it's such
> > an easy fix.
>
> > 2. I was also wondering if there's a reason that the dictionary of
> > numbers/letters used in that function is in such a seemingly random
> > order... is there some brilliant logic behind it?
>
> > The source for the function I'm referring to is here:
>
> >http://code.djangoproject.com/browser/django/trunk/django/utils/text
>
> > Thanks!
>
> >     - Gabriel
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Speeding up test running

[ptone]

This is probably just a curiosity, but I was playing with ways to test
the raw power of my new 8-core mac pro and was looking at how to apply
this to testing.

By using multiprocessing I was able to reduce the running of the
current trunk tests from 6 minutes to 3.

Because a test case needs to be pickled to be pushed to the worker
pool and not all test cases could be, almost 2 minutes of this is
spent having to run just several tests in the main thread.  If this
was resolved, I think the whole test suite could be run in about a
minute.

When it hits a stretch of tests that can be dispatched and lights up
all cores, it just screams.

With the increase of multicore machines, perhaps this is something of
interest.  Even with fast fail - waiting for tests to run takes away
from other development tasks, and being able to run the test suite
more frequently would probably help catch some bugs earlier before
they cascade or propagate by being extended or referred to.  I'll
grant this is a relatively low priority - but if anyone wants, I'd be
happy to clean up my hack and post it as a gist.

-Preston
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Porting Django to Python 3

[Łukasz Rekucki]

2010/1/14 Marty Alchin :
> On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey  wrote:
>> Martin's approach was single codebase where the 3.x version for execution is
>> generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
>> I'm wondering if this difference is accounted for by 2to3?  If yes, then it
>> is not necessarily a problem that would stand in the way of maintaining
>> single Django source and supporting Python 2.x and 3.x simultaneously.
>
> Yes, I was a bit less clear than I should've been. I was responding on
> an assumption that the author was expecting a single codebase to work
> with 2 and 3 without going through 2to3 in between.
That is what I meant. And I believe it is possible even with those
syntactic diffrences.

> To my knowledge,
> 2to3 does handle all the syntactic issues between the two, but I just
> wanted to make it clear that it's definitely not "pretty much the same
> as supporting old 2.x pythons."
I'm not saying it is *as easy*. Surely, it's more complicated and
requires more work.

And actually, I agree with that 2to3 already handles most of this
stuff, so it's the right way to go. At least now. What I really wanted
to say, is that using 2to3 on a 2.6 code that uses (for example)
__future__.unicode_literals is more likely to succed.

>
> -Gul
>

-- 
Łukasz Rekucki
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: help needed: non-relational DB support

[Waldemar Kornewald]

On Thu, Jan 14, 2010 at 2:42 PM, Russell Keith-Magee
 wrote:
> Speaking for myself, I'm pretty busy trying to get features completed
> before the 1.2 feature deadline. At the moment, anything that isn't on
> the 1.2 roadmap is only getting cursory attention from me. I suspect
> the same is true of most of the other core developers, and anyone else
> that is closely involved in the Django development process.

Do you think you can work with us in the 1.3 release cycle? In the
meantime we can try to back-port SQL as far as possible. We really
need to get this into 1.3 and some support from the Django core team
would be great.

> However, if I might offer some advice: my experience has been that
> large features like this aren't developed by large groups. They are
> developed by one or two people working closely. It's only when the
> functionality is mostly complete that other people offer help, mostly
> in the form of testing.

We are two developers who work closely together, but we don't feel
very comfortable hacking through the SQL layer without any help.

Bye,
Waldemar Kornewald

--
http://twitter.com/wkornewald
http://bitbucket.org/wkornewald/
http://allbuttonspressed.blogspot.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-develop...@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: Porting Django to Python 3

[Marty Alchin]

On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey  wrote:
> Martin's approach was single codebase where the 3.x version for execution is
> generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
> I'm wondering if this difference is accounted for by 2to3?  If yes, then it
> is not necessarily a problem that would stand in the way of maintaining
> single Django source and supporting Python 2.x and 3.x simultaneously.

Yes, I was a bit less clear than I should've been. I was responding on
an assumption that the author was expecting a single codebase to work
with 2 and 3 without going through 2to3 in between. To my knowledge,
2to3 does handle all the syntactic issues between the two, but I just
wanted to make it clear that it's definitely not "pretty much the same
as supporting old 2.x pythons."

-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-develop...@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: Porting Django to Python 3

[Karen Tracey]

On Thu, Jan 14, 2010 at 2:17 PM, Marty Alchin  wrote:

> 2010/1/14 Łukasz Rekucki :
> > It is possible to write 3.x code that is backwards-compatible with
> > python 2.6+. There are some rough edges like, names of stdlib modules,
> > instance checks for strings and some introspection details. In my
> > opinion, it's pretty much the same as supporting old 2.x pythons.
>
> In many cases, this is true, but there are other scenarios (certain
> forms of exception handling, for example) where there is no syntax
> that's valid in both versions. That's syntax, not just libraries and
> functions. There's no way to even get a file to parse in both Python 2
> and Python 3 in these situations. There are certainly places in Django
> that will run into these, so we really can't have a single codebase
> that's completely compatible with both branches.
>
>
Martin's approach was single codebase where the 3.x version for execution is
generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
I'm wondering if this difference is accounted for by 2to3?  If yes, then it
is not necessarily a problem that would stand in the way of maintaining
single Django source and supporting Python 2.x and 3.x simultaneously.

Karen
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, 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: Porting Django to Python 3

[Marty Alchin]

2010/1/14 Łukasz Rekucki :
> It is possible to write 3.x code that is backwards-compatible with
> python 2.6+. There are some rough edges like, names of stdlib modules,
> instance checks for strings and some introspection details. In my
> opinion, it's pretty much the same as supporting old 2.x pythons.

In many cases, this is true, but there are other scenarios (certain
forms of exception handling, for example) where there is no syntax
that's valid in both versions. That's syntax, not just libraries and
functions. There's no way to even get a file to parse in both Python 2
and Python 3 in these situations. There are certainly places in Django
that will run into these, so we really can't have a single codebase
that's completely compatible with both branches.

-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-develop...@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: Porting Django to Python 3

[Łukasz Rekucki]

2010/1/14 Jesus Mager :
> Hi!
>
> I don't think we can have a library working on python 2 and at the
> same time on python 3.(Dont know if 3to2 is a good solution).
It is possible to write 3.x code that is backwards-compatible with
python 2.6+. There are some rough edges like, names of stdlib modules,
instance checks for strings and some introspection details. In my
opinion, it's pretty much the same as supporting old 2.x pythons.

>The converting process, IMHO, should be prepared for a mayor release of
> Django, may be django 2 and let python 2 without support for these
> version. But maintaining 2 libraries at the same time will be really
> confusing.
> I Know, Django 1.x is at now very young, but, what about starting the
> ideas for the nee mayor release.
> Just ideas...
As a Django user I would be very unhappy to know, that after spending
lots of time making my app python 3.x compatible, now I have to port
it to a newer backwards-incompatible Django2 (and again, wait for all
applications I use to do the same).

>
> 2010/1/13 Josh Roesslein :
>> From my experience with the 2to3 tool, it's no silver bullet for
>> porting to 3. I have had plenty of cases where manual tweeking of the
>> code was needed. The tool does help a lot on getting trivial things
>> changed over, but certain things it just can't do. Now this is with a
>> very small library of mine, django is a lot more complex.
>>
>> I'd think doing the initial porting be done with Git or such to allow
>> for better collaboration.
>> Once the porting is done it should be moved into Django's SVN as a
>> seprate branch with an assigned
>> manager(s) who's duty is to merge in any changes in the 2.x branch.
>> While this might sound taxing, it's fairly
>> easy to do and can even be automated in some cases. Simply when ever a
>> commit occurs in 2.x auto apply it to
>> the 3.x branch then run the tests. If all pass, finalize the commit
>> and be done. If tests fail, fire off an error email to the person
>> responsible for the 3.x branch so they can fix it. You can even run
>> the 2to3 tool to try fixing any issues.
>>
>> So
>>
>> On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey  wrote:
>>> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:

 2010/1/13 Tobias McNulty :
 > I am by no means an expert on the matter, but I remember seeing a
 > comment
 > awhile back suggesting that it generally makes more sense to fix the
 > 2to3
 > script than to maintain two branches of the same library. Might that be
 > the
 > case here as well?

 Py3K does not support old-style classes. Django uses these quite a
 lot, for instance the Meta-class of a model is old-style. I don't
 think it is in any way possible to have an automatic script convert
 these in a sensible way as django is deliberately utilizing the
 difference between old and new style in no doubt a django-specific
 way. If django on 2.x could be rewritten to no longer depend on
 old-style classes, and was made to depend on python 2.6 or newer, then
 2to3 would have a chance to do its magic.

>>>
>>> I'm no expert either, but as I understanding it maintaining single source
>>> for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
>>> 3.x version during install may be a viable option.  This is the approach
>>> that was taken by Martin v. Löwis when he got an initial port working back
>>> in late 2008:
>>>
>>> http://wiki.python.org/moin/PortingDjangoTo3k
>>>
>>> He cites bugs in 2to3 as a barrier to getting the approach to work at that
>>> time, but doesn't note anything insurmountable he ran across in the Django
>>> source.  It is true the port only verified that getting through the tutorial
>>> worked, but that covers the basics of models certainly.
>>>
>>> Karen
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to django-develop...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-developers+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>>
>>
>
>
>
> --
> Jesus Mager
> [www.h1n1-al.blogspot.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-develop...@googlegroups.com.
> To 

Re: Model validation incompatibility with existing Django idioms

[Raffaele Salmaso]

Raffaele Salmaso wrote:
> Joseph Kocherhans wrote:
>> regressions?
> http://code.djangoproject.com/ticket/12577
Ok, BaseGenericInlineFormSet doesn't have save_new to save the generic fk.pk
Reenabled and everything go as before.

-- 
()_() | That said, I didn't actually _test_ my patch.  | +
(o.o) | That's what users are for! | +---+
'm m' |   (Linus Torvalds) |  O  |
(___) |  raffaele dot salmaso at gmail dot 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-develop...@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: Sessions: does set_expiry has a max value?

[Karen Tracey]

On Thu, Jan 14, 2010 at 11:07 AM, Pablo López  wrote:

> I know, but it looked a django bug, that is why I posted here, because
> I think it makes more sense discussing about _potential_ django bugs
> with their developers than doing it with their users. I'll search
> better for next time.
>
>
Note if you are quite sure you have found a bug, the right place to go is
the tracker. Search there, and it you don't find that it has already been
reported, open a ticket. There is no need to get clearance from the
developer's list first (but please do search first). Most bugs don't require
discussion on the dev list, it's only when the bug raises some design
question that discussion might be taken to the list.

If you aren't sure, the right place to ask is the user's list. You are not
limiting your audience that way: far more people read -users than
-developers, and core developers read and participate in discussions on the
user's list. You may well get a quicker answer there than here.  If it does
seem like a genuine unreported bug someone will likely ask you to open a
ticket in the tracker for it.

This list: http://docs.djangoproject.com/en/dev/internals/contributing/#id1is
useful for getting a sense of what is the preferred approach to use
for
various situations.

Karen
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, 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: Sessions: does set_expiry has a max value?

[Pablo López]

I know, but it looked a django bug, that is why I posted here, because
I think it makes more sense discussing about _potential_ django bugs
with their developers than doing it with their users. I'll search
better for next time.

Pablo

On 14 ene, 16:54, Waylan Limberg  wrote:
> On Thu, Jan 14, 2010 at 10:50 AM, Pablo López  wrote:
> > I *did* search in this group... not in others :-)
>
> > Thank you anyway
>
> Ah, well for future reference, django-dev is specifically for the
> development *of* django. For help with using django you should always
> go to django-users.
>
> --
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Sessions: does set_expiry has a max value?

[Waylan Limberg]

On Thu, Jan 14, 2010 at 10:50 AM, Pablo López  wrote:
> I *did* search in this group... not in others :-)
>
> Thank you anyway
>

Ah, well for future reference, django-dev is specifically for the
development *of* django. For help with using django you should always
go to django-users.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Sessions: does set_expiry has a max value?

[Karen Tracey]

On Thu, Jan 14, 2010 at 10:50 AM, Pablo López  wrote:

> I *did* search in this group... not in others :-)
>
>
Note django-users is the more appropriate group for this question.
Questions about using Django should go to django-users, django-developers if
for discussions focused on developing Django itself.

Karen
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, 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: Sessions: does set_expiry has a max value?

[Pablo López]

I *did* search in this group... not in others :-)

Thank you anyway

On 14 ene, 16:41, Gonzalo Riestra  wrote:
> Hi Pablo,
>
> First of all, welcome to Django community.
>
> You should search at the forum before asking anything...Here you have
> the solution:
>
> http://groups.google.com/group/django-users/browse_thread/thread/323c...
>
> Gonzalo Riestra
>
> On 14 ene, 12:52, Pablo López  wrote:
>
>
>
> > Hi everyone!
>
> > In my login function in views.py I make use of set_expiry function to
> > set the cookie expriry time depending on the selection of a "remember
> > me" checkbox on the login form:
>
> > if not form.cleaned_data["rememberme"]:
> >     request.session.set_expiry(0)
> > else:
> >     request.session.set_expiry(2592000) # one month
>
> > This works ok, but if I increase the set_expiry in just one second for
> > the else case (2592001), the user does *not* log in, although it sets
> > the expiry time correctly for the cookie (I know how weird it sounds).
>
> > In my settings.py, I have commented the SESSION_COOKIE_AGE variable in
> > case that could be the source of the problem, but I get the same
> > behaviour.
>
> > # Sessions
> > SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
> > #SESSION_COOKIE_AGE = 2592000
> > #SESSION_EXPIRE_AT_BROWSER_CLOSE = True
>
> > My question is: is there a max value for the set_expiry value? If not,
> > any ideas why the user does not get logged in?
>
> > Thank you in advance!
>
> > Pablo L.
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Sessions: does set_expiry has a max value?

[Gonzalo Riestra]

Hi Pablo,

First of all, welcome to Django community.

You should search at the forum before asking anything...Here you have
the solution:

http://groups.google.com/group/django-users/browse_thread/thread/323cdc612547709c

Gonzalo Riestra


On 14 ene, 12:52, Pablo López  wrote:
> Hi everyone!
>
> In my login function in views.py I make use of set_expiry function to
> set the cookie expriry time depending on the selection of a "remember
> me" checkbox on the login form:
>
> if not form.cleaned_data["rememberme"]:
>     request.session.set_expiry(0)
> else:
>     request.session.set_expiry(2592000) # one month
>
> This works ok, but if I increase the set_expiry in just one second for
> the else case (2592001), the user does *not* log in, although it sets
> the expiry time correctly for the cookie (I know how weird it sounds).
>
> In my settings.py, I have commented the SESSION_COOKIE_AGE variable in
> case that could be the source of the problem, but I get the same
> behaviour.
>
> # Sessions
> SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
> #SESSION_COOKIE_AGE = 2592000
> #SESSION_EXPIRE_AT_BROWSER_CLOSE = True
>
> My question is: is there a max value for the set_expiry value? If not,
> any ideas why the user does not get logged in?
>
> Thank you in advance!
>
> Pablo L.
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Juan Pablo Scaletti]

If an AnonymousUser can do something then everybody can do that as well.
So why a regular unprotected view can't do the job?

On Thu, Jan 14, 2010 at 8:13 AM, Harro  wrote:

> I was having a look at the new 1.2 row level permission support that
> got added and ran into the problem that the AnonymousUser does not
> call the authentication backend functions.
>
> The default backend doesn't need this, but with a custom backend I
> might want to implement Guest permissions.
>
> I think it will make the permission system even more powerful !
>
> What do you guys think?
>
>
> Ticket: http://code.djangoproject.com/ticket/12557
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>
>


-- 

Juan Pablo Scaletti
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Sessions: does set_expiry has a max value?

[Pablo López]

Hi everyone!

In my login function in views.py I make use of set_expiry function to
set the cookie expriry time depending on the selection of a "remember
me" checkbox on the login form:

if not form.cleaned_data["rememberme"]:
request.session.set_expiry(0)
else:
request.session.set_expiry(2592000) # one month

This works ok, but if I increase the set_expiry in just one second for
the else case (2592001), the user does *not* log in, although it sets
the expiry time correctly for the cookie (I know how weird it sounds).

In my settings.py, I have commented the SESSION_COOKIE_AGE variable in
case that could be the source of the problem, but I get the same
behaviour.

# Sessions
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
#SESSION_COOKIE_AGE = 2592000
#SESSION_EXPIRE_AT_BROWSER_CLOSE = True

My question is: is there a max value for the set_expiry value? If not,
any ideas why the user does not get logged in?

Thank you in advance!

Pablo L.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: Porting Django to Python 3

[Josh Roesslein]

>From my experience with the 2to3 tool, it's no silver bullet for
porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.

I'd think doing the initial porting be done with Git or such to allow
for better collaboration.
Once the porting is done it should be moved into Django's SVN as a
seprate branch with an assigned
manager(s) who's duty is to merge in any changes in the 2.x branch.
While this might sound taxing, it's fairly
easy to do and can even be automated in some cases. Simply when ever a
commit occurs in 2.x auto apply it to
the 3.x branch then run the tests. If all pass, finalize the commit
and be done. If tests fail, fire off an error email to the person
responsible for the 3.x branch so they can fix it. You can even run
the 2to3 tool to try fixing any issues.

So

On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey  wrote:
> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:
>>
>> 2010/1/13 Tobias McNulty :
>> > I am by no means an expert on the matter, but I remember seeing a
>> > comment
>> > awhile back suggesting that it generally makes more sense to fix the
>> > 2to3
>> > script than to maintain two branches of the same library. Might that be
>> > the
>> > case here as well?
>>
>> Py3K does not support old-style classes. Django uses these quite a
>> lot, for instance the Meta-class of a model is old-style. I don't
>> think it is in any way possible to have an automatic script convert
>> these in a sensible way as django is deliberately utilizing the
>> difference between old and new style in no doubt a django-specific
>> way. If django on 2.x could be rewritten to no longer depend on
>> old-style classes, and was made to depend on python 2.6 or newer, then
>> 2to3 would have a chance to do its magic.
>>
>
> I'm no expert either, but as I understanding it maintaining single source
> for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
> 3.x version during install may be a viable option.  This is the approach
> that was taken by Martin v. Löwis when he got an initial port working back
> in late 2008:
>
> http://wiki.python.org/moin/PortingDjangoTo3k
>
> He cites bugs in 2to3 as a barrier to getting the approach to work at that
> time, but doesn't note anything insurmountable he ran across in the Django
> source.  It is true the port only verified that getting through the tutorial
> worked, but that covers the basics of models certainly.
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: M2M Column Names Changed in 1.2 - Breaks Backwards Compatibility

[Russell Keith-Magee]

On Thu, Jan 14, 2010 at 3:13 PM, simonb  wrote:
> I think this ticket http://code.djangoproject.com/ticket/12386
> identifies a change in the m2m code which breaks backwards
> compatibility.

Hi Simon,

I'm aware of the ticket - there are a couple of tickets that I need to
take a look at regarding potential regressions in m2m behaviour.
#12386 is on that list.

Thanks for taking the time to narrow down a specific failing case.
That helps tremendously.

Yours,
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: M2M Column Names Changed in 1.2 - Breaks Backwards Compatibility

[Harro]

Hmm where did the foreign key go on the 1.2 example?

And I must say that the name for the modelc column is a bit weird.


On Jan 14, 8:13 am, simonb  wrote:
> I think this tickethttp://code.djangoproject.com/ticket/12386
> identifies a change in the m2m code which breaks backwards
> compatibility.
>
> Consider the following three apps and models:
>
> AppA/models.py:
>
> class ModelA(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>
> AppB/models.py:
>
> class ModelB(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>     ma = models.ManyToManyField('AppA.ModelA', blank=True, null=True,
> related_name='mb')
>     mc = models.ManyToManyField('AppC.ModelC', blank=True, null=True,
> related_name='mc')
>
> AppC/models.py:
>
> class ModelC(models.Model):
>     name = models.CharField(max_length=1024, default='', blank=True)
>
> The SQL generated for the m2m fields in AppB is different for Django
> 1.1 and 1.2/trunk. This breaks backwards compatibility.
>
> It seems that in some cases 1.2 names the m2m column 'app.model_id'
> whereas 1.1 uses 'model_id' only - i.e. no 'app.'
>
> This only seems to happen when there are more that one m2m fields in a
> model. Tested with postgresql. The SQL output for the M2M table is
> show below for the different Django versions.
>
> Django 1.1
>
> CREATE TABLE "AppB_modelb_mc" (
>     "id" serial NOT NULL PRIMARY KEY,
>     "modelb_id" integer NOT NULL REFERENCES "AppB_modelb" ("id")
> DEFERRABLE INITIALLY DEFERRED,
>     "modelc_id" integer NOT NULL REFERENCES "AppC_modelc" ("id")
> DEFERRABLE INITIALLY DEFERRED,
>     UNIQUE ("modelb_id", "modelc_id")
> );
>
> Django 1.2
>
> CREATE TABLE "AppB_modelb_mc" (
>     "id" serial NOT NULL PRIMARY KEY,
>     "modelb_id" integer NOT NULL,
>     "appc.modelc_id" integer NOT NULL,
>     UNIQUE ("modelb_id", "appc.modelc_id")
> );
>
> 1.1 = "modelc_id"
> 1.2 = "appc.modelc_id"
>
> I've uploaded a little test project to the ticket which demonstrates.
>
> Simon
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

AnonymousUser has_perm/has_module_perms function check authentication backends

[Harro]

I was having a look at the new 1.2 row level permission support that
got added and ran into the problem that the AnonymousUser does not
call the authentication backend functions.

The default backend doesn't need this, but with a custom backend I
might want to implement Guest permissions.

I think it will make the permission system even more powerful !

What do you guys think?


Ticket: http://code.djangoproject.com/ticket/12557
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: phone2numeric doesn't convert "Q" or "Z"

[Harro]

hmm that's indeed weird. The regex excludes those as well
specifically.
The Q and Z should be added or a comment should be added to the code
explaining the reason for leaving them out.

On Jan 14, 11:23 am, Gabriel Hurley  wrote:
> 1. Is there a reason Django's phone2numeric method doesn't work for
> the letters Q or Z? I realize that those two letters are the ones that
> share four letters to a number instead of the standard three, but
> that's no reason to leave them out. Most modern phones include the
> full alphabet on their keys and it's silly not to let people convert
> those two letters.
>
> If there's no reason, I'd be happy to submit a patch since it's such
> an easy fix.
>
> 2. I was also wondering if there's a reason that the dictionary of
> numbers/letters used in that function is in such a seemingly random
> order... is there some brilliant logic behind it?
>
> The source for the function I'm referring to is here:
>
> http://code.djangoproject.com/browser/django/trunk/django/utils/text
>
> Thanks!
>
>     - Gabriel
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, 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: help needed: non-relational DB support

[Thomas Wanschik]

On Jan 8, 1:10 pm, Waldemar Kornewald  wrote:
> Hi,
> our non-relational port has come to the point where we need to
> back-port the SQL layer to the query backend API (i.e., the new
> query_class()). We could need some help from Django developers who
> know the ORM internals really well. You can find a little introduction
> to the code 
> here:http://bitbucket.org/wkornewald/django-nonrel-multidb/wiki/Home
>
> It would be great if one core developer could join the project and
> actually work on the code. Here's the discussion 
> group:http://groups.google.com/group/django-non-relational
>
> The difficulty is that we need to convert QuerySet's intermediate
> representation (QueryData) to the sql.Query representation. We're not
> sure if QueryData in its current implementation has the right format
> and someone who knows sql.Query better than we do could be of great
> help, especially with the conversion process. Our goal is to get
> non-relational backend support into Django 1.3 (which is definitely
> possible, so please don't vote -1 next time if this is your only
> concern).
>
> I understand if you're currently busy with finishing 1.2, but if
> you're interested in helping when will you have time?
>

Is nobody out there with a little bit of time/interest in helping?
It would be really nice and would speed up the development of
supporting non-relational databases for Django.

Bye,
Thomas Wanschik

> Bye,
> Waldemar Kornewald
>
> --http://twitter.com/wkornewaldhttp://bitbucket.org/wkornewald/http://allbuttonspressed.blogspot.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-develop...@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: phone2numeric doesn't convert "Q" or "Z"

[Łukasz Rekucki]

2010/1/14 Gabriel Hurley :
> 2. I was also wondering if there's a reason that the dictionary of
> numbers/letters used in that function is in such a seemingly random
> order... is there some brilliant logic behind it?
Yes, there is. Someone probably copy it from python's output,
so they're in python's hash order.
If you type into the console:
>>> {'a': 2, 'b': 2, 'c': 2}
{'a': 2, 'c': 2, 'b': 2}
Notice that 'b' and 'c' and reversed. Of course it's a dictionery, so
it doesn't really matter.


> The source for the function I'm referring to is here:
>
> http://code.djangoproject.com/browser/django/trunk/django/utils/text.py#L158
>
> Thanks!
>
>    - Gabriel

-- 
Łukasz Rekucki
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

phone2numeric doesn't convert "Q" or "Z"

[Gabriel Hurley]

1. Is there a reason Django's phone2numeric method doesn't work for
the letters Q or Z? I realize that those two letters are the ones that
share four letters to a number instead of the standard three, but
that's no reason to leave them out. Most modern phones include the
full alphabet on their keys and it's silly not to let people convert
those two letters.

If there's no reason, I'd be happy to submit a patch since it's such
an easy fix.

2. I was also wondering if there's a reason that the dictionary of
numbers/letters used in that function is in such a seemingly random
order... is there some brilliant logic behind it?

The source for the function I'm referring to is here:

http://code.djangoproject.com/browser/django/trunk/django/utils/text.py#L158

Thanks!

- Gabriel
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.