Re: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.

Luke Plant wrote: > I imagine the atheists on this list find it even more annoying, In the meanwhile we, the agnostic ones, simply skip it. ;-) -- Nicola Larosa - http://www.tekNico.net/ That's what *professionals* do. They are always learning. Always. Because nothing you learn about what's "

Re: runtest.py slowdowns?

On 5/14/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/15/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > Has anyone noticed a fairly recent order of magnitude slowdown in how > > long it takes to run the django test suite? I used to get times of > > about 14 seconds around M

Re: runtest.py slowdowns?

On 5/15/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Has anyone noticed a fairly recent order of magnitude slowdown in how > long it takes to run the django test suite? I used to get times of > about 14 seconds around March (at PyCon) but it's taking ~150 seconds > now. It's quite possibly

Re: Caching querysets

How about caching the return of qs.iterator()? Would that work? Ben On 15/05/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > I'd like to propose an addition to the low-level caching API that > fills the queryset _result_cache if the value being set (or contained > in a sequence or dictionary bei

runtest.py slowdowns?

Has anyone noticed a fairly recent order of magnitude slowdown in how long it takes to run the django test suite? I used to get times of about 14 seconds around March (at PyCon) but it's taking ~150 seconds now. It's quite possibly something that's changed in my setup, but I figured I'd see if any

Re: Caching querysets

Jeremy Dunck wrote: > Do people think it's worth doing? Have you seen the (accepted) object-level caching summer of code project? http://code.google.com/soc/django/appinfo.html?csaid=EFBF229544BAC5D0 --~--~-~--~~~---~--~~ You received this message because you are

[sqlalchemy] SQLAlchemy branch questions

Hi all, I don't wish to rake over the debate on the database connection - newbie questiondebate which I followed with

Re: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.

On 5/14/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 May 2007 01:09:08 Secret wrote: > > There is a section below with the title "Atheism and Evolution are > > WRONG." > > > > All those who have sinned deserve to suffer in Hell forever. "Pride" > > is an example of a terrible sin. >

Re: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.

On Tuesday 15 May 2007 01:09:08 Secret wrote: > There is a section below with the title "Atheism and Evolution are > WRONG." > > All those who have sinned deserve to suffer in Hell forever. "Pride" > is an example of a terrible sin. As a Christian, I am extremely embarrassed by this kind of inapp

+ Important: Repent, Completely trust in God only and, Love Him with all of your heart.

There is a section below with the title "Atheism and Evolution are WRONG." All those who have sinned deserve to suffer in Hell forever. "Pride" is an example of a terrible sin. 1. Repent (be truly sorry for your sins; beg for God's forgiveness; abandon sin; ask Him to help you stop sinning; and

Caching querysets

I'd like to propose an addition to the low-level caching API that fills the queryset _result_cache if the value being set (or contained in a sequence or dictionary being set) is a queryset. Consider that before magic-removal, the ORM returned actual lists, so that something like this was producti

Widget rendering and access to "parts" in a template

Good morning, I have been looking at how to best provide a break-out of a few fields in newforms to my template designers. In corresponding with Malcolm on django-users, I found out that you couldn't break down the form input into it's parts directly from within a template - primarily because Bou

Making part of a MultiValueField optional

This may be better suited for django-users, as it's somewhat a usage question, but it's for DurationField, which is a proposed addition to Django itself, and its solution may (I don't know yet, just guessing) involve some slight code changes. I'm planning to implement a SplitDurationField, based

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

On 5/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > What's your ETA on these changes? I finally have some free time this > week, and I'd like to work toward getting this branch finalized. If > you don't have time to hack on this, let me know where you left off. I'm still working on the for

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Everything switched around again in [5237]. Excellent. Thanks, Malcolm! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscr

Re: Changeset [5231] -- do_clean_*() is awkward naming

On Mon, 2007-05-14 at 10:52 -0500, Adrian Holovaty wrote: > On 5/14/07, John Shaffer <[EMAIL PROTECTED]> wrote: > > For me, an AttributeError from clean_data is a much more friendly > > change than silently ignoring code like: > > > > def clean_email(self): > > """Prevent account hijac

Re: Changeset [5231] -- do_clean_*() is awkward naming

> For me, an AttributeError from clean_data is a much more friendly > change than silently ignoring code like: True, and the AttributeError can even be user-friendly: class BaseForm(StrAndUnicode): [...] _clean_data_error(self): raise AttributeError("clean_data has been replaced by cleane

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, John Shaffer <[EMAIL PROTECTED]> wrote: > For me, an AttributeError from clean_data is a much more friendly > change than silently ignoring code like: > > def clean_email(self): > """Prevent account hijacking by disallowing duplicate emails.""" John makes an excellent poin

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > That was exactly why I didn't change clean_data (my initial "fix" was > just to name it cleaned_data). It's already used in lots of code, so the > impact of change it is larger. Changing the undocumented feature is less > disruptive. Unne

Re: Changeset [5231] -- do_clean_*() is awkward naming

> What about clean_data -> cleaned_data and maintain clean_*() I would go for this. cleaned_data sounds a lot more more adequate anyway. > The biggest down side is that clean_data is already documented... but > it's an easy find-replace As newforms is not fully documented so far and some parts

Re: Changeset [5231] -- do_clean_*() is awkward naming

On Mon, 2007-05-14 at 10:58 -0400, Benjamin Slavin wrote: > On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > I think we should try to stay with the "cleaning" line of thinking, > > rather than validate- or normalise-related terms, just for consistency, > > though. > > Agreed. > > >

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I think we should try to stay with the "cleaning" line of thinking, > rather than validate- or normalise-related terms, just for consistency, > though. Agreed. What about clean_data -> cleaned_data and maintain clean_*() The biggest d

Re: Changeset [5231] -- do_clean_*() is awkward naming

On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I think we should try to stay with the "cleaning" line of thinking, > rather than validate- or normalise-related terms, just for consistency, > though. Sounds like time to visit Ye Olde Thesaurus... Off the top of my head: scrub or wash

Re: Changeset [5231] -- do_clean_*() is awkward naming

+1 cleanfield_foo() On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-05-14 at 09:11 -0500, Adrian Holovaty wrote: > > Hi there, > > > > I just spotted changeset [5231]: > > > > """ > > Renamed form-specific cleaning methods to be do_clean_*, rather than > clean_*. > > T

Re: Changeset [5231] -- do_clean_*() is awkward naming

On Mon, 2007-05-14 at 09:11 -0500, Adrian Holovaty wrote: > Hi there, > > I just spotted changeset [5231]: > > """ > Renamed form-specific cleaning methods to be do_clean_*, rather than clean_*. > This avoids a name clash that would occur when you had a form field called > "data" (because clean_

Changeset [5231] -- do_clean_*() is awkward naming

Hi there, I just spotted changeset [5231]: """ Renamed form-specific cleaning methods to be do_clean_*, rather than clean_*. This avoids a name clash that would occur when you had a form field called "data" (because clean_data is already a dictionary on the Form class). """ http://code.djangopro

Re: Two field-related suggestions for newforms.models

On 5/14/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > 2) I realize that there are historical (i.e., > > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > > and M2M relations are not contained on forms, but is

Re: Design Query: How to handle transition to "FloatField version 2"

Malcolm Tredinnick wrote: > (3) Find another name for the new, genuine FloatField. Problem > is, "FloatField" is a really good name. All other names I can > think of are longer or non-Pythonic (e.g. NumericField only > makes sense if you think "SQL", not "Python").

Re: Design Query: How to handle transition to "FloatField version 2"

On Mon, 2007-05-14 at 09:49 +, simonbun wrote: > What if we would make the 'decimal_places' argument illegal for the > new FloatField? That exception would make the change impossible to > miss. Hope I'm not missing anything obvious with this idea, it just > popped into my head. Doh! Yes... th

Re: Design Query: How to handle transition to "FloatField version 2"

What if we would make the 'decimal_places' argument illegal for the new FloatField? That exception would make the change impossible to miss. Hope I'm not missing anything obvious with this idea, it just popped into my head. On May 14, 11:25 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I ha

Design Query: How to handle transition to "FloatField version 2"

I had a patch all ready to commit, doing the long-awaited FloatField -> DecimalField change and putting in a "real" FloatField. Then I realised I was about to do something silly. Renaming FloatField to DecimalField is simple and obvious. The backwards-incompatible change means people have to do a

Re: Two field-related suggestions for newforms.models

On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Two suggestions about the newforms API: I'm late to the party on this one, but here are some thoughts -- > 1) Is there room for a 'fields' argument on form_for_instance and > form_for_model - a list of field names that you want include