Re: BCrypt + Python3

Apologies for answering so late. I see the change discussed here was already committed. The change itself is fine — essentially because it's limited to the bcrypt password hasher — but I'd like to bring some perspective to parts of this discussion. Overall, I strongly advocate consistency in

Proposal: better support for generating rest apis in django core

Hi, We was talked with Russell on djangocon eu about integrating more rich support for working django as rest api provider, focused on dealing with one-page web applications. The motivations that currently without third party modules like django-rest-framework or tastypie its quite impossible

deprecating ipaddressfield (at some time)

Hello all, Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField. The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does normalisation of IPv6 addresses. It can also be configured to only accept IPv4 or IPv6 addresses. As far as I know,

Re: test discovery

Hi all, On Fri, 10 May 2013, Carl Meyer wrote: I merged this patch tonight. Thanks to everyone who contributed! Now let's see how the CI servers feel about it... I think Travis is unhappy about something in this commit. Any ideas?

Re: BCrypt + Python3

On May 18, 2013, at 5:15 AM, Aymeric Augustin wrote: > Apologies for answering so late. I see the change discussed here was already > committed. The change itself is fine — essentially because it's limited to > the bcrypt password hasher — but I'd like to

Re: RFC: "universal" view decorators

On May 18, 2013, at 8:57 AM, Marc Tamlyn wrote: > I'm going to resurrect this old thread as I'd like to get it resolved in some > fashion. > > I used to be very in favour of the class decorators approach. I've been using > an implementation of

looking up date as str (fails under Oracle, Ticket #20015)

Hi django devs, While going through Oracle bugs, I ran into the ticket in the subject[0]. The problem there is that current code assumes that whenever we want to compare anything (pretty much) against a datetime column, in any way, we'd like to compare the column value and the given value as

Re: test discovery

Hi Chris, On May 18, 2013, at 9:42 AM, Chris Wilson wrote: > Another odd behaviour of the new test runner. This runs the tests, but fails > to add the test app to INSTALLED_APPS, so they all fail because their tables > are not created: > >PYTHONPATH=.. python -Wall

Re: test discovery

Hi Chris, On May 18, 2013, at 8:34 AM, Chris Wilson wrote: > On Sat, 18 May 2013, Chris Wilson wrote: > >> I think Travis is unhappy about something in this commit. Any ideas? >> >> == >> ERROR:

Making __repr__ safe by default

As suggested by Marc Tamlyn I am posting this here for discussion: https://code.djangoproject.com/ticket/20448 tl;dr: Currently __repr__() calls __unicode__() which can be a very bad thing. You really don't want things like an exception being raised or debugger being used to cause additional

Re: test discovery

Hi Carl, On Sat, 18 May 2013, Carl Meyer wrote: I don't think this should be fixed in the test runner itself; in general, file-path test labels _should_ be interpreted as relative to wherever you are running the tests from. But it should be fixed in the

Re: looking up date as str (fails under Oracle, Ticket #20015)

On 18 touko, 17:46, Shai Berger wrote: > Hi django devs, > > While going through Oracle bugs, I ran into the ticket in the subject[0]. The > problem there is that current code assumes that whenever we want to compare > anything (pretty much) against a datetime column, in any

Re: Making __repr__ safe by default

On 18 touko, 19:04, Patryk Zawadzki wrote: > As suggested by Marc Tamlyn I am posting this here for discussion: > > https://code.djangoproject.com/ticket/20448 > > tl;dr: > > Currently __repr__() calls __unicode__() which can be a very bad > thing. You really don't want

Re: looking up date as str (fails under Oracle, Ticket #20015)

On Saturday 18 May 2013 19:35:31 Anssi Kääriäinen wrote: > On 18 touko, 17:46, Shai Berger wrote: > > > > 1) The fixes I see would affect all backends, but AFAIK only Oracle is > > reported as failing the test; anyone wants to comment on this? Do all > > other backends just

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

On 16 touko, 11:20, Danilo Bargen wrote: > As a sidenote, there was a discussion about this on this mailing list a few > months ago: > > https://groups.google.com/forum/#!searchin/django-developers/16550/dj... I think a pre_sync signal is best approach. The signal should be

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

I can try to implement approach with pre_syncdb signal tomorrow. I think that is quite enough solution before deeper diggling into new migrations framework. Karol 18 maj 2013 19:03, "Anssi Kääriäinen" napisał(a): > On 16 touko, 11:20, Danilo Bargen

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

There's already a patch on the ticket tracker for a pre_syncdb signal, and yesterday I started updating it and modifying it a bit as I needed this signal. https://github.com/dstufft/django/compare/pre-syncdb-signal On May 18, 2013, at 1:06 PM, Karol Sikora wrote: > I can

Model field validation (of the field itself, not values)

Good afternoon, I am currently working on writing a small number of subclasses to `models.Field`. As part of doing this, I wanted to add validation to how those fields are instantiated, and discovered that I think it can't be done. Assuming I'm right, I'd like to fix it. Here's the use case.

Re: Model field validation (of the field itself, not values)

Hey Luke - Yup, this is indeed a problem. It's actually the subject of a Summer of Code proposal [1], so if you can wait there's a good chance that you won't have to do any work yourself :) Jacob [1] https://groups.google.com/forum/#!msg/django-developers/e0-rOIkrXaQ/w5aiW_R6aFYJ On Sat, May

Ticket #9321 -- Modelform widgets help text for ManyToMany fields

Hi all, This is a proposal for fixing this small and old issue (https://code.djangoproject.com/ticket/9321): Model forms for models that include a ManyToMany field get a hard-coded "*Hold down "Control", or "Command" on a Mac, to select more than one." sentence in the respective help text

ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]

On Saturday 18 May 2013 19:49:58 Shai Berger wrote: > > I'm toying with a different solution now -- removing the date casting on > Oracle too. It passed the lookup tests, now I'm running the whole suite > (that takes a little time). After seeing that no other backend in core > does it, and as we

Re: ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]

Oopsie: On Sunday 19 May 2013 08:12:12 Shai Berger wrote: > ...They do pass on our CI [0],... http://ci.djangoproject.com/job/Django%20Oracle/lastCompletedBuild/database=oracle,python=python2.7/ Thanks, Shai. -- You received this message because you are subscribed to the Google