yes/no option for BooleanField

2006-09-07 Thread Gary Wilson
After noticing the new NullBooleanField, I am thinking it would be nice to have the same sort of yes/no dropdown option for BooleanField (without the "unknown" choice of course). What do you think? --~--~-~--~~~---~--~~ You received this message because you are s

do timesince and timeuntil template filters really need millisecond resolution?

2006-09-07 Thread Gary Wilson
Just seems a bit silly to 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-developers@googlegroups.com To unsubscribe from this group, send e

Re: App portability

2006-09-07 Thread Jay Parlar
On 9/7/06, Nate Straz <[EMAIL PROTECTED]> wrote: > Wow, I never knew about that syntax. I checked the Language Reference > all the way back to the 1.5 release and it is in every release. I'm > surprised I've never seen that syntax used before. > > Thank you for pointing that out. The reason yo

Re: App portability

2006-09-07 Thread Nate Straz
On Fri, Sep 08, 2006 at 03:18:22AM +0200, Daniel Poelzleithner wrote: > in myapps/views.py: > from .models import Somemodel > > which will import from myapps/models.py Somemodel > > from ..otherapp.models import Othermodel > > imports from myapps/../otherapp/models.py -> otherapps/models.py >

Re: App portability

2006-09-07 Thread Daniel Poelzleithner
Martin Glueck wrote: > Be careful ... in one of the next releases of python, support for > relative import will be dropped! So I would suggest that you don't > rely on relative import in new written code and change it whenever you > find it in old code. It will not be droped in 2.5 but it will b

Re: Small change to utils.functional.curry

2006-09-07 Thread Michael Spencer
Marc D.M. wrote: > On Wed, 2006-09-06 at 22:49 -0700, Michael Spencer wrote: >> If you're really hunting for speed, there is a significant boost available >> in >> the common special case of a python function curried with one positional >> argument. In this case, you can [ab]use the method bin

Re: Small change to utils.functional.curry

2006-09-07 Thread Michael Spencer
Marc D.M. wrote: > On Thu, 2006-09-07 at 13:28 -0500, Adrian Holovaty wrote: >> On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote: >> >>> If you're really hunting for speed, there is a significant boost available >>> in >>> the common special case of a python function curried with one positio

Re: Small change to utils.functional.curry

2006-09-07 Thread Marc D.M.
On Thu, 2006-09-07 at 13:28 -0500, Adrian Holovaty wrote: > On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote: > > Martin's version is indeed faster, but has a 'gotcha' in that it precludes > > passing a keyword arguments named 'fct' to a curried function... > > [...] > > Better to rename fct t

Re: App portability

2006-09-07 Thread Malcolm Tredinnick
On Thu, 2006-09-07 at 03:41 +, SmileyChris wrote: > When moving an app to a different project, I had to go through and fix > all the references to my project name in code. Is there a better way to > import my code? Currently I import like: > > from projectname.appname.models import Model > >

Re: Small change to utils.functional.curry

2006-09-07 Thread Adrian Holovaty
On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote: > Martin's version is indeed faster, but has a 'gotcha' in that it precludes > passing a keyword arguments named 'fct' to a curried function... > [...] > Better to rename fct to something less likely to clash, such as _curried_fct Good call, M

Re: Re: Small change to utils.functional.curry

2006-09-07 Thread James Bennett
On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote: > Martin's version is indeed faster, but has a 'gotcha' in that it precludes > passing a keyword arguments named 'fct' to a curried function... If you look at the changeset checked in by Adrian[1], it's slightly different than Martin's origina

Re: Small change to utils.functional.curry

2006-09-07 Thread Marc D.M.
On Wed, 2006-09-06 at 22:49 -0700, Michael Spencer wrote: > If you're really hunting for speed, there is a significant boost available in > the common special case of a python function curried with one positional > argument. In this case, you can [ab]use the method binding machinery, e.g.: > >

Re: App portability

2006-09-07 Thread JP
You don't need to physically move an app from project to project to use the app in different projects. An app is just a python package. Say you have app 'foo' from project 'bar' and you want to use it in a new project, 'baz'. Install bar somewhere in your python path and then add bar.foo to the IN

i18n generation problem

2006-09-07 Thread zeuxis
Hi, I'm trying to update some of the django's message files ... and I get errors (because of non-named arguments in formatted strings) in contrib/admin/views/doc.py. Thoses errors seem to stop the updating process. Z. --~--~-~--~~~---~--~~ You received

Re: App portability

2006-09-07 Thread Pedro Lima
What about having a directory inside the project but also in the python path for keeping shared applications. Then just code the applications like from appname.models import Model and it's easy to move those applications between projects. Regards, Pedro --~--~-~--~~---