On May 7, 10:18 pm, Armin Ronacher
wrote:
> Heyho,
>
> On May 7, 10:01 pm, Marty Alchin wrote:> It's not
> explicitly related to the MRO and method stuff you and Alex
> > have been working on, but it's definitely related to the r9766
> > discussion, since it's caused by the delayed saving. I ha
Heyho,
On May 7, 10:01 pm, Marty Alchin wrote:
> It's not explicitly related to the MRO and method stuff you and Alex
> have been working on, but it's definitely related to the r9766
> discussion, since it's caused by the delayed saving. I have a clear
> understanding of the problem, but I don't
On Thu, May 7, 2009 at 3:43 PM, Armin Ronacher
wrote:
> On May 7, 5:37 pm, Karen Tracey wrote:
>> #10249: can't create consistent MRO (method resolution order) when assigning
>> a File to a FileField.
> This is fixed.
I was reading over the patch Alex mentioned in IRC (yay for
DjangoBot's logge
Hi,
On May 7, 5:37 pm, Karen Tracey wrote:
> #10249: can't create consistent MRO (method resolution order) when assigning
> a File to a FileField.
This is fixed.
> #10300: custom storage backend can't get length of content to save.
This *should* be fixed. I can't test it, no access to S3.
> #
On Thu, May 7, 2009 at 12:05 PM, Armin Ronacher
wrote:
> I'm working with Alex on that right now here in Prague. We have some
> branches on github related to that. Basically the idea is to start
> with getting rid of some of the over engineering in the abstract base
> classes and make sure the
On Thu, May 7, 2009 at 11:37 AM, Karen Tracey wrote:
> I noticed the question of what to do about the r9766-related issues came up
> in the 1.1 thread so figured, in case it's helpful, I'll lay out my
> understanding of what/where these are.
You've been doing some great working tracking these is
Hi,
On May 7, 5:37 pm, Karen Tracey wrote:
> So far as I know there 4 open ticks remaining related to r9766. Three are
> regressions so I believe something really needs to be done about them before
> 1.1; one I think is just a bug in the new function. Personally I'd rather
> not revert the new
2009/5/7 Matt Boersma
>
>
> On May 6, 2009, at 8:50 PM, Karen Tracey wrote:
>
> On Wed, May 6, 2009 at 10:34 PM, Leo Soto M. <
> leo.s...@gmail.com> wrote:
>
>>
>> While testing the django-jython oracle backend I get an ugly failure
>> on model_forms_regress,
>
>
> Yes, I saw this too. I'll ch
I noticed the question of what to do about the r9766-related issues came up
in the 1.1 thread so figured, in case it's helpful, I'll lay out my
understanding of what/where these are.
So far as I know there 4 open ticks remaining related to r9766. Three are
regressions so I believe something reall
On Thu, May 7, 2009 at 8:34 AM, Jacob Kaplan-Moss
wrote:
> Ugh, I really hate not being able to just assign files to fields. It
> just feels hacky and wrong to call instance.file_field.save(). It'll
> also break a bunch of code folks have written over the last few
> months. I know, no backwards-c
On Thu, May 7, 2009 at 12:43 PM, Jacob Kaplan-Moss wrote:
> I'm hard at work punting tickets out of the 1.1 milestone. It's tough
> to do, but this is what time-based releases mean: sometimes you have
> to ship with known issues.
Update: I've pushed/closed all the issues I plan to. We're now at
On Thu, May 7, 2009 at 1:09 PM, Marty Alchin wrote:
> While I still think that's a valuable feature, and will likely be
> required in order to complete Honza's model validation work for GSOC,
> it's really a new feature that has so far caused far more bugs than
> it's worth. I'd like to recommend
On 7 May 2009, at 01:11, Russell Keith-Magee wrote:
>
> On Wed, May 6, 2009 at 5:33 PM, daonb wrote:
>>
>> Hi all,
>> I'm a part of the Django user group in Israel and we want to have our
>> own project, taking a part of the Django project and improving it.
>> I've discussed it with Jacob, Adri
On Thu, May 7, 2009 at 6:43 AM, Jacob Kaplan-Moss wrote:
> Once this is done we'll be down to blockers for 1.1; many of us at the
> sprint are focusing on these. More help will be appreciated!
I just wanted to add a note here that may have some impact on which
tickets get punted vs. fixed in 1.1
Hi folks --
The EuroDjangoCon sprints have started, and we're hacking hard to get
1.1 out the door. Here's the plan:
I'm hard at work punting tickets out of the 1.1 milestone. It's tough
to do, but this is what time-based releases mean: sometimes you have
to ship with known issues.
Now, we can'
On Thu, May 7, 2009 at 5:18 PM, daonb wrote:
>
>> * Builtin support for the full Atom publishing protocol. This is
>> already logged as ticket (#3569) and was originally accepted for v1.1,
>> but got delayed in the interest of the schedule.
>
> Makes sense to support RFC 4287. I think it will he
> * Builtin support for the full Atom publishing protocol. This is
> already logged as ticket (#3569) and was originally accepted for v1.1,
> but got delayed in the interest of the schedule.
Makes sense to support RFC 4287. I think it will help if we drop RSS
support and support only Atom. I'm +
On Thu, May 7, 2009 at 4:26 AM, James Bennett wrote:
> relying on a bug in Django which allowed BooleanField to accept any of
> three values rather than restricting it to either of two values.
And I misspoke there, thinking of a different bug. Now that I look at
it you couldn't even assign a nul
Thanks Alex/George
I second the point that a buggy release is what we would not want. As
one of the third party module developer, I just wanted to keep myself
updated about it. Thus, was just curious to know if there is any
strict schedule already been followed and not updated on the website.
Tha
On Thu, May 7, 2009 at 3:30 AM, Tai Lee wrote:
> BooleanField(null=True) indicates that the field can have null values
> in the database (or does already have null values in the case of an
> existing database), but that any objects created or edited via Django
> must specify one of two values, tr
I just noticed in recent versions of Django that BooleanField
(null=True) will raise a validation warning, indicating that I should
use NullBooleanField instead. This doesn't make sense, and is mixing
up the definition of a model field in SQL and the behaviour of a model
field in Django.
BooleanF
21 matches
Mail list logo
