This is a huge release, folks!
Lots of big ticket items. Lots of lovely toys for everyone to play with:)
And still very backward compatible?
I reckon you'll have the beta out before I've even finished playing with
everything...
Power on, people! Keep up the massive works!
--
Curtis
On 23
Yup, we're on the way to 1.7!
Check out the blog post (which mentions a couple of important issues to be
aware of *before* trying out the alpha):
https://www.djangoproject.com/weblog/2014/jan/22/django-17-alpha-1-released/
And the in-progress 1.7 release notes for a full rundown of what's going
On Thu, Jan 23, 2014 at 8:29 AM, Shai Berger wrote:
> Hi,
>
> I took a look at PR 2192[1] earlier, and noted that checks.register keeps
> being used as a function, called from AppConfig.ready(), and not as a
> decorator; but it is defined as a decorator, so it looks a little funny:
>
> ch
Hi,
I took a look at PR 2192[1] earlier, and noted that checks.register keeps
being used as a function, called from AppConfig.ready(), and not as a
decorator; but it is defined as a decorator, so it looks a little funny:
checks.register('models')(check_generic_foreign_keys)
(from the c
On Wed, Jan 22, 2014 at 9:31 PM, Hannu Krosing wrote:
>
> What about moving this kind of migration support from database driver
> to django core as an universal fallback ?
>
Definitely not! It's an awful way of doing migrations and only exists
because people use SQLite a lot for development; I'd
On 01/22/2014 08:59 AM, Shai Berger wrote:
>> This means we're really only left with:
>>> 3) The database backend or driver doesn't support altering the schema in a
>>> way that would work with Django's schema migrations API. I can't think of
>>> any that would be used with Django, but people still
Hi everyone,
First I'd like to say I got bitten by this in the past. What worries
me the most in the original report is the TEMPLATE_DEBUG part. IMHO,
this should fail loudly regardless of any debug settings.
As for other stuff:
On 22 January 2014 18:34, Ramiro Morales wrote:
> I think you are
On Wed, Jan 22, 2014 at 12:26 PM, Andrew Godwin wrote:
> On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre wrote:
>
>>
>> My request would probably be better read as "Must a database backend
>> support schema alterations?", which also implies its ability to do a
>> migration that alters the schema
On Wed, Jan 22, 2014 at 1:12 PM, Henrique Romano wrote:
>
> That was just an example, ugettext_* returns a functional.proxy, which
> doesn't try to render the string when you print it on the screen, but if you
> try to do it you will see the same result.
You are right.
On Wed, Jan 22, 2014 at 1:
On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre wrote:
>
> My request would probably be better read as "Must a database backend
> support schema alterations?", which also implies its ability to do a
> migration that alters the schema. Data only migrations would still
> technically be possible wit
On Wednesday 22 January 2014 19:15:08 Michael Manfre wrote:
>
> I think we all agree that any database backend must continue to be able to
> create or delete schema objects, or provide something like Oracle's
> TEST_CREATE setting to allow that to be done as a non-Django step.
Actually, I don't;
On Wednesday 22 January 2014 18:58:26 Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 2:38 PM, Shai Berger wrote:
> > I don't think Django should take responsibility for a 3rd-party package
> > which
> > decides that some part of a setting should be translatable whether the
> > user said so or no
On Wed, Jan 22, 2014 at 6:40 AM, Andrew Godwin wrote:
> My thoughts in brief on this:
>
> - Database backends don't support migrations - they support schema
> alteration via SchemaEditor. This could be used separately from migrations
> if something wants it, and is meant to be an API on its own,
On Wed, Jan 22, 2014 at 2:38 PM, Shai Berger wrote:
> I don't think Django should take responsibility for a 3rd-party package
> which
> decides that some part of a setting should be translatable whether the user
> said so or not.
>
> You might want to take this up with django-cms.
Not exactly t
On Wed, Jan 22, 2014 at 12:43 PM, Ramiro Morales wrote:
> You aren't telling us all the story. there are many missing parts in your
> description of the issue you are finding so far so I don't think it's right
> to jump straight to the "As per the documentation, it is not clear that
> you _must_
On Wednesday 22 January 2014 18:29:18 Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 2:16 PM, Shai Berger wrote:
> > Wait -- so the real context (which, as Ramiro noted, you left out) is
> >
> > # settings.py
> >
> > LANGUAGES = (('pt_BR', _("Português")),)
> >
> > Is it? Or is it
> >
> > LA
On Wed, Jan 22, 2014 at 2:16 PM, Shai Berger wrote:
>
> Wait -- so the real context (which, as Ramiro noted, you left out) is
>
> # settings.py
>
> LANGUAGES = (('pt_BR', _("Português")),)
>
> Is it? Or is it
>
> LANGUAGES = (('pt_BR', "Português"),)
>
> If it is the former, then this is a generic
On Wednesday 22 January 2014 18:01:14 Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 12:39 PM, Shai Berger wrote:
> > This has nothing to do with the LANGUAGES setting, or the string being a
> > language name. it just so happens that ugettext tries to return unicode,
> > and
> > so for an untran
On Wed, Jan 22, 2014 at 12:39 PM, Shai Berger wrote:
>
> This has nothing to do with the LANGUAGES setting, or the string being a
> language name. it just so happens that ugettext tries to return unicode,
> and
> so for an untranslated string s it returns unicode(s). You can get the same
> error
yes i will try with django 1.6.
2014/1/22 Henrique Romano
> On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves <
> gsa...@gmail.com> wrote:
>
>> please look details about on [1]. if you put
>>
>> # -*- coding: utf-8 -*- on sources and config files for django your string
>> "português
On Wed, Jan 22, 2014 at 10:59 AM, Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves <
> gsa...@gmail.com> wrote:
>
>> please look details about on [1]. if you put
>>
>> # -*- coding: utf-8 -*- on sources and config files for django your string
>> "português" wi
On Wednesday 22 January 2014 15:59:23 Henrique Romano wrote:
> On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves <
>
> gsa...@gmail.com> wrote:
> > please look details about on [1]. if you put
> >
> > # -*- coding: utf-8 -*- on sources and config files for django your
> > string "portu
On Wed, Jan 22, 2014 at 11:38 AM, gilberto dos santos alves <
gsa...@gmail.com> wrote:
> please look details about on [1]. if you put
>
> # -*- coding: utf-8 -*- on sources and config files for django your string
> "português" will be automatically handled.
>
>
Can you just try what I reported?
please look details about on [1]. if you put
# -*- coding: utf-8 -*- on sources and config files for django your
string "português" will be automatically handled.
regards.
[1] http://docs.python.org/2/howto/unicode.html
2014/1/22 Henrique Romano
> Hi,
>
> On Wed, Jan 22, 2014 at 12:37 AM,
Hi,
On Wed, Jan 22, 2014 at 12:37 AM, gilberto dos santos alves <
gsa...@gmail.com> wrote:
> please see that it is python directive not django. for all sources it is a
> good practive for all we that use pt-br utf-8 explicit this on second line
> of file python code
>
> # -*- coding: utf-8 -*-
>
My thoughts in brief on this:
- Database backends don't support migrations - they support schema
alteration via SchemaEditor. This could be used separately from migrations
if something wants it, and is meant to be an API on its own, so the backend
is not the place to say if you want migrations or
On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote:
> On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger wrote:
> >
> > B) Allow the test suite to run on an existing schema. The Oracle backend
> > already does this (badly) -- its six specific TEST_* parameters are
> > awkwardly named, but
2014/1/22 Michael Manfre
> Currently unknown level of effort or complexity to allow the migrations
> to fallback to a Django 1.6 syncdb-esque behavior.
>
Assuming that cost isn't too high, another concern is our ability to
maintain this feature: since none of the core backends will use it,
it ma
On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger wrote:
> Hi,
>
> (quotations reordered a little)
>
> On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote:
> > On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre
> wrote:
> > > *Why Disable Migrations?*
> > >
> > > 1) Not all projects need sch
29 matches
Mail list logo
