On 2/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 2/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > Open tickets. Reporting problems is what tickets are for, and there is
> > already a value of documentation for the component of a problem report
> > (although it might be an id
On 2/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have significant experience with MS SQL server 2000, and have access
> to an instance to test against. I have found very little
> documentation on Trac about this in tickets or the wiki. I am also
> willing to help with Windows installe
On Fri, 2007-02-09 at 23:59 -0600, Adrian Holovaty wrote:
> On 2/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > My recommendation in there is that we stop screwing around with builtins
> > and just import the thing directly and alias it in each module. We are
> > trying to be too clever.
On 2/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> My recommendation in there is that we stop screwing around with builtins
> and just import the thing directly and alias it in each module. We are
> trying to be too clever. I don't really like breaking Python's existing
> use of _ as we ar
On 2/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Open tickets. Reporting problems is what tickets are for, and there is
> already a value of documentation for the component of a problem report
> (although it might be an idea to have a 'code cleanup' category for
> reporting inline comme
On 2/9/07, David Abrahams <[EMAIL PROTECTED]> wrote:
> Entry.objects.filter(
> _.headline.startswith('What') &
> ~(_.pub_date>=datetime.now()) &
> _.pub_date>=datetime(2005, 1, 1))
David,
Looks like you don't like Django's database API. Sorry you don't like
it, but we can
On 2/9/07, Rubic <[EMAIL PROTECTED]> wrote:
> I've not been following the newforms admin branch, but I
> wondered if it could be decoupled from reliance upon
> TEMPLATE_STRING_IF_INVALID == ''
>
> It's often useful to have something like 'BADDATA' assigned
> to TEMPLATE_STRING_IF_INVALID during de
On 2/8/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> I have opened a ticket about it:
> #3463 - EmptyQuerySet's iterator() method does not return a generator
> http://code.djangoproject.com/ticket/3463
>
> Please review.
Fixed in http://code.djangoproject.com/changeset/4475 . Thanks for the patch!
On 2/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> This changeset only affects the running of the Django model/regression
> tests, not the unit/doctests of an end user.
>
> Although running ./runtests.py requires a settings file, the only
> thing the settings file should be providing are
On Sat, 2007-02-10 at 12:54 +0800, Russell Keith-Magee wrote:
> On 2/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > Hey Adrian,
> >
> > I have some concerns about this changeset.
> ...
> > Since the idea is that Django's test framework can also be used to test
> > our own application
On 2/10/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Adrian,
>
> I have some concerns about this changeset.
...
> Since the idea is that Django's test framework can also be used to test
> our own applications and projects, I think we need to respect what is
> already in this setting a
"James Bennett" <[EMAIL PROTECTED]>
writes:
> First thoughts: subjectively, I'm not sure it'd be any prettier than
> what we have now.
Can't argue with your subjective opinion. But I suggest you ask some
newbies what they think. Also, "prettiness" is not really one of my
goals, though I belie
Hey Adrian,
I have some concerns about this changeset.
On Fri, 2007-02-09 at 22:01 -0600, [EMAIL PROTECTED] wrote:
> Author: adrian
> Date: 2007-02-09 22:01:19 -0600 (Fri, 09 Feb 2007)
> New Revision: 4473
>
> Modified:
>django/trunk/tests/runtests.py
> Log:
> Improved runtests.py to normal
Hey Russ,
On Sat, 2007-02-10 at 12:09 +0800, Russell Keith-Magee wrote:
> Hi all,
>
> I've been working on the test system again, trying to get #3162 merged
> in. The ticket itself is no big drama, but it does expose a larger
> problem with the i18n system that is causing some drama. I18n isn't
Hi all,
I've been working on the test system again, trying to get #3162 merged
in. The ticket itself is no big drama, but it does expose a larger
problem with the i18n system that is causing some drama. I18n isn't
really my specialty, so I'd appreciate any assistance in sorting this
problem out.
First thoughts: subjectively, I'm not sure it'd be any prettier than
what we have now. I'm also wary of overloading the concepts of the
standard Python operators when whet we're really doing is translating
to SQL operations -- sooner or later, there's going to be an impedance
mismatch.
I'm also n
Malcolm Tredinnick <[EMAIL PROTECTED]>
writes:
> On Fri, 2007-02-09 at 21:14 -0500, David Abrahams wrote:
>> _.foo >= 6 returns an expression tree, an object that represents
>> the comparison of the foo field with 6. This technique is well-known
>> among advanced C++ programmers but has also be
On Fri, 2007-02-09 at 21:14 -0500, David Abrahams wrote:
> Malcolm Tredinnick <[EMAIL PROTECTED]>
> writes:
[...]
> > Maybe I'm missing something, but I don't see how this can work at all.
> > When Python sees "_.foo >= 6", it is going to evaluate it at runtime
> > (before calling the function).
"Lawrence Oluyede" <[EMAIL PROTECTED]>
writes:
>> > ---
>> > from django.models import field as _
>> >
>> > Entry.objects.filter(
>> > _.headline.startswith('What')).exclude(
>> > _.pub_date>=datetime.now()).filter(
>> > _.pub_date>=datetime(2005, 1, 1))
>>
>> Should b
> > ---
> > from django.models import field as _
> >
> > Entry.objects.filter(
> > _.headline.startswith('What')).exclude(
> > _.pub_date>=datetime.now()).filter(
> > _.pub_date>=datetime(2005, 1, 1))
>
> Should be:
>
> Entry.objects.filter(
> _.headline.startswith(
Malcolm Tredinnick <[EMAIL PROTECTED]>
writes:
> On Sat, 2007-02-10 at 08:30 +0800, Russell Keith-Magee wrote:
>> On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>> >
>> >Use natural operators for filtering, excluding, and attribute
>> >access.
>>
>> > How about it?
>>
>> Some imm
"Russell Keith-Magee"
<[EMAIL PROTECTED]> writes:
> On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>>
>>Use natural operators for filtering, excluding, and attribute
>>access.
>
>> How about it?
>
> Some immediate problems:
>
> - Your syntax works for < > <= >= and ==; but what abo
On Sat, 2007-02-10 at 08:30 +0800, Russell Keith-Magee wrote:
> On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
> >
> >Use natural operators for filtering, excluding, and attribute
> >access.
>
> > How about it?
>
> Some immediate problems:
>
> - Your syntax works for < > <= >= an
Have it all working now, am about to update #2720
--~--~-~--~~~---~--~~
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 fro
On Feb 10, 1:41 pm, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Interesting. I'm guessing it's not wired up to request.POST... I tried
> naming my form like name="name.key" and got no DotExpandedDict love. :)
You'd just do the following line:
post = DotExpandedDict(request.POST)
then you'll have s
On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>
>Use natural operators for filtering, excluding, and attribute
>access.
> How about it?
Some immediate problems:
- Your syntax works for < > <= >= and ==; but what about all the other
Django query operators? How do you come up with
On Fri Feb 09, 2007 at 02:54:44PM -0800, SmileyChris wrote:
>
> Hi Rob, there's similar functionality in Django already (but it's
> undocumented afaik) using a custom data structure called
> DotExpandedDict:
> http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215
Just wanted to say how useful the recent triage pass (and classification
of tickets) has been after having time to get back to Django after a
break. It is much easier to work out likely tickets to work on now that
the "obviously insufficient" stuff has already been weeded out.
Thanks, guys. Reall
On Wed, 2007-01-31 at 17:41 -0800, Rob Hudson wrote:
> > Keep in mind that django.contrib.contenttypes gets installed by
> > default, and is used by the comments app, the auth app, the admin app
> > and the generic relations framework.
> >
> > It's hard to escape it :)
>
> I quickly grepped the
Hi Rob, there's similar functionality in Django already (but it's
undocumented afaik) using a custom data structure called
DotExpandedDict:
http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215
I just opened a ticket regarding it's undocumented nature.
--~--~---
David Abrahams
<[EMAIL PROTECTED]> writes:
> ---
> from django.models import field as _
>
> Entry.objects.filter(
> _.headline.startswith('What')).exclude(
> _.pub_date>=datetime.now()).filter(
> _.pub_date>=datetime(2005, 1, 1))
Should be:
Entry.objects.filter(
What's wrong with this picture?
TimeDivision.objects.filter(when__ge=datetime(2007,5,14))
Whoops. "Greater or equal" is spelled 'gte' and not 'ge' in Django's
model API. After having fallen into this trap and getting a cryptic
error message (UnboundLocalError: local variable 'new_opts' refer
Hi, thanks for looking at this, it's a lot of words/work for a minor
issue- getting db foreign key constraints working in an M2M edge case.
I'm working on my first patch. It's actually a patch to a patch,
#2720, which exposes an issue that came up with an inter-app M2M
field. _get_many_to_many_sq
This is obviously borrowed from PHP but I think there are useful
reasons to copy this behavior.
The idea...
If one constructs their HTML forms, naming their form elements as
"name[key]" like so:
etc.
Django would then convert this to a dictionary of form:
f = {
'name': 'value
Marc Fargas Esteve wrote:
> But psycopg1 is obsolete so newcomers should be recommended to version
> use 2 unless there are still outstanding issues with it.
Am I right that psycopg2 extracts string as unicode (I really don't
know)? If yes then unicode will go straight into models' attributes an
I've not been following the newforms admin branch, but I
wondered if it could be decoupled from reliance upon
TEMPLATE_STRING_IF_INVALID == ''
It's often useful to have something like 'BADDATA' assigned
to TEMPLATE_STRING_IF_INVALID during development/testing
because such text easy to scan unfors
I'd like to do some code profiling of my application/projects, and I'm
confused about how to go about it. I found a wiki entry that
references hotshot, but I'm not sure where to go from here.
http://code.djangoproject.com/wiki/ProfilingDjango
--~--~-~--~~~---~--~
In response to:
> b = Blog.objects.get(id=1)
> [ I do some other things here, and meanwhile the title of blog with
> id=1 was changed]
> for entry in b.entry_set.all():
> entry.blog is b # Is this still true?
> entry.blog.title is b.title # How about this?
I understand how this could hap
2007/2/9, Marc Fargas Esteve <[EMAIL PROTECTED]>:
[...]
> And something released six months ago (version 2.0 was released on 8th
> June 2006) is not that new.
[...[
> To check the dates yourself:
> * http://initd.org/pub/software/psycopg/ChangeLog-1.1
> * http://initd.org/pub/software/psycopg/
I'm trying to put in the cache a simple Python list made of unicode
strings. The strange thing is locmem crashes badly during the first
retrieval of a cache hit. The same code with the simple backend is
like a breeze.
I looked into locmem.py and simple.py backends and as the traceback
states the
On 2/8/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> But set_password will only set a sha1 password. So why would the
> global check_password need to check if the algo is 'md5' if
> set_password could never use md5?
Django used to use MD5 hashes; that function is in there so that an
old installati
(moving to django-developers since that's where this sort of discussion belongs)
On 2/9/07, Jon Colverson <[EMAIL PROTECTED]> wrote:
> Adrian and Jacob didn't think that it was worth posting to
> django-announce about it, since it only affects newforms. The
> justification given was that newforms
Marc Fargas Esteve:
> It is obsole because upstream says so:
> # PsycopgOne -- the original psycopg 1.1.x (now obsoleted by psycopg 2)
> # PsycopgTwo -- psycopg 2.0, the one you shall use
>(from: http://www.initd.org/tracker/psycopg/wiki)
>
> If upstream says something is obsolete you
On 09-Feb-07, at 4:35 PM, Marc Fargas Esteve wrote:
> It is obsole because upstream says so:
> # PsycopgOne -- the original psycopg 1.1.x (now obsoleted by
> psycopg 2)
> # PsycopgTwo -- psycopg 2.0, the one you shall use
>(from: http://www.initd.org/tracker/psycopg/wiki)
>
> If up
It is obsole because upstream says so:
# PsycopgOne -- the original psycopg 1.1.x (now obsoleted by psycopg 2)
# PsycopgTwo -- psycopg 2.0, the one you shall use
(from: http://www.initd.org/tracker/psycopg/wiki)
If upstream says something is obsolete you should stop using it ;) On
the
On 09-Feb-07, at 3:08 PM, Marc Fargas Esteve wrote:
> But psycopg1 is obsolete
in what way is it obsolete? works fine for me - I dont believe in
upgrading to a new and backwardly incompatible version just because
it is new. What are they benefits of pyscopg2 over 1?
--
regards
kg
http://
And I use windows 3.1 'cause I prefer it! Just joking ;)
But psycopg1 is obsolete so newcomers should be recommended to version
use 2 unless there are still outstanding issues with it. They can
always go to psycopg1 if they want ;)
On 2/9/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>
>
> On
> Good point. I did a quick test and the SHA-1 hashes are equivalent...
I also tried with Python 2.3
[EMAIL PROTECTED] ~ % python2.3
[10:08]
Python 2.3.5 (#1, Jan 13 2006, 20:13:11)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license"
48 matches
Mail list logo
