On 3/5/06, kmh <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > We could get really carried away here, but I'm not sure if there is
> > any gain. The problem you are describing has existed since pre-MR days
> > (and can be seen living large in the unit tests), and while it is an
> > i
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
> >
> > My concern is that you end up with this:
> >
> > book.authors = [author1, author2]
> > book.authors == [author1, author2] # not true
>
> Well, if we want to get picky like that, then book.authors should
> evaluate as
On 3/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Is it worth either fixing the attribute lookup to return None in the
> above case, or adding a self.source.exists attribute (returns true or
> false)? Then we can truly hide all references to source_id.
Hi Malcolm,
I'm in the process of
On 3/5/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> Of course, with problems like stack limits I was encountering, you can't
> guarantee it will work for larger volumes of data, because it will
> depend on the size of 'many' in 'many-to-one', but for day-to-day usage
If you find another case that
Tom Tobin wrote:
> Having found myself fiending for regular expression lookups in Django,
> I implemented the behavior in ticket #1465. It has a few caveats:
> case-sensitive regexes only work in PostgreSQL, PCRE-ish regexes only
> work in PostgreSQL and sqlite (the other backends use POSIX "exte
I think regex searching is a great idea, and actually was about to do
the same thing for mysql a while back.
I would love to see this go into the mainstream, as most of my users
are more familiar with Perl RegEx's than SQL like syntax.
so +1 from me.
On 3/5/06, Tom Tobin <[EMAIL PROTECTED]> wro
Having found myself fiending for regular expression lookups in Django,
I implemented the behavior in ticket #1465. It has a few caveats:
case-sensitive regexes only work in PostgreSQL, PCRE-ish regexes only
work in PostgreSQL and sqlite (the other backends use POSIX "extended"
regexes), and regula
On Saturday 04 March 2006 14:47, Russell Keith-Magee wrote:
> The unit tests all pass with this change. However, I don't have a
> readily available source of 2 interrelated objects to stress test
> the algorithm. Could you please check that this 1) actually fixes
> your problem, and 2) gives
On 3/4/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> But your patch fixes things for me - thanks!
Good to hear. I've committed it to magic removal as r2487. Thanks for
your (and Malcolm's) help in tracking this one.
> I haven't been able to find a nice solution. You can't even do
> something like
On Saturday 04 March 2006 07:17, Russell Keith-Magee wrote:
> This becomes a Heisenbug because the hashcode given to dict keys (and
> thus the original order of dict.keys()) is runtime dependent. The
> more dependencies/discovered classes you have, the worse the problem
> gets (explaining Luke's
Resending this as a new thread, the old one was pages back in Google
groups, and it probably needs attention from someone like Adrian/Jacob.
It's another puzzler (and comes logically before the previous thread
about delete).
On Sunday 26 February 2006 03:15, Russell Keith-Magee wrote:
> Inter
On Sat, 2006-03-04 at 15:17 +0800, Russell Keith-Magee wrote:
> On 3/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > OK, it's weirder than you think, though.
>
> Oh.. I don't know... I think it's pretty weird :-)
>
> > I get the same failure whether
> > I run all the tests or only Lu
12 matches
Mail list logo
