Re: [ANNOUNCE] Django 1.7 alpha 1 released

[Curtis Maloney]

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 January 2014 15:13, James Bennett  wrote:

> 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
> to be in the final release:
>
> https://docs.djangoproject.com/en/dev/releases/1.7/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg-b0mNWphessOC8WdM2MZb-NRVvZk1H8gcvqPaAx%2BhupQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DY48UeW9Hcu1e0RcV-snW%3Dhg%3DsujH6wUomTGQCMhVsA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANNOUNCE] Django 1.7 alpha 1 released

[James Bennett]

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 to
be in the final release:

https://docs.djangoproject.com/en/dev/releases/1.7/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-b0mNWphessOC8WdM2MZb-NRVvZk1H8gcvqPaAx%2BhupQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: django.core.checks.register shouldn't be (primarily) a decorator

[Russell Keith-Magee]

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:
>
> checks.register('models')(check_generic_foreign_keys)
>
> (from the contenttypes AppConfig, for example).
>
> Registering checks only in ready(), rather than at import time, is now the
> way
> to do things, so register() should typically not be used as a decorator; I
> think we should change its definition accordingly, to
>
> def register(self, check, *tags)
>
> Thoughts?
>
> [1] https://github.com/django/django/pull/2192


That's a fair point. The decorator mode of registration has effectively
been deprecated by the move to using ready() (since there's almost
certainly no way to use it in practice. Altering the prototype to reflect
this makes sense to me.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-xRN7KSvTq3S7UAZaSBNerCHr6T6_OF6V0JqhPXMs-dg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

django.core.checks.register shouldn't be (primarily) a decorator

[Shai Berger]

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 contenttypes AppConfig, for example).

Registering checks only in ready(), rather than at import time, is now the way 
to do things, so register() should typically not be used as a decorator; I 
think we should change its definition accordingly, to 

def register(self, check, *tags)

Thoughts?

[1] https://github.com/django/django/pull/2192

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401230229.31275.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Andrew Godwin]

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 personally like to
remove it someday, but that seems unlikely.



>
> My argument for this is that it is remarkably hard to do schema
> migrations properly even for backends which "support it". You do not
> want to end up with 3 days downtime "while the database migrates"
> because you trusted django to do the right thing and it worked ok in
> your (small) test database.
>
> Automatic migrations are very useful at development time, but need
> lots of TLC when done in production environment. They are hard enough
> to orchestrate propery at pure SQL level. Adding an extra layer on top
> with largely undefined performance characteristics makes things much
> more complikated still.
>

And this is why we have the sqlmigrate command so that you can get the SQL
and tweak it if you like without having to write it manually in the first
place.

South/django.db.migrations is actually relatively useful in production on
the bottom 95% of websites provided you're using PostgreSQL; most
operations it performs don't lock anything, and it's probably better than
your average programmer at writing DDL SQL. If you're in that top 5% and
have an actually sizeable database, then yes, you should look at the
scripts it produces, but it's still very useful for developers to use as
they make new features and the SQL it makes is usually an excellent start
if you want to hand-run the migration (and if it was just an ADD COLUMN
with NULL, then I'd let Django do it anyway as I know that's instantaneous
and lock-free, and Django handles all the transaction management around
migrations so it can roll back if things error).

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urxD6p_qDN476zngAHyvTLc9RFWv6PLW-%2BrksC2yOuA-A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Hannu Krosing]

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 use mysql despite its
>>> many faults, so anything is possible.
>> This one, which seems unlikely.
> Actually, SQLite "doesn't support altering the schema in a way that would 
> work 
> with Django's schema migrations API". The SQLite backend bends over backwards 
> to comply; its implementation of "alter column" is "recreate the table, 
> copying the data". AFAIK it doesn't quite get everything right, even with the 
> somersaults it pulls; and yet, it's close enough for comfort.
What about moving this kind of migration support from database driver
to django core as an universal fallback ?

(btw, creating a new table and copying the data is what PostgreSQL
does in the background for ALTER TABLE ALTER COLUMN TYPE for many,
but not all column type changes)

My argument for this is that it is remarkably hard to do schema
migrations properly even for backends which "support it". You do not
want to end up with 3 days downtime "while the database migrates"
because you trusted django to do the right thing and it worked ok in
your (small) test database.

Automatic migrations are very useful at development time, but need
lots of TLC when done in production environment. They are hard enough
to orchestrate propery at pure SQL level. Adding an extra layer on top
with largely undefined performance characteristics makes things much
more complikated still.

Just my two 2 cents
Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/52E038A9.9020208%40krosing.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Łukasz Rekucki]

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 onto something re: the fact that we don't make clear
> that our ugettext*() functions fail to accept encoded literals with
> characters outside ASCII under Python 2.x. even when the encoding
> metadata is correct.

I think everyone is forgetting  that those are *u*gettext() functions
and they work fine with any literals as long as the argument type is
unicode, because that is the only type they know how to handle. The
implicit bytes->text conversion in Python 2 makes this a little less
obvious, but the expected argument type is in the name.

IMHO, It would be better for everyone if ugettext_lazy() and friends
fail immediately when given anything other then text (unicode on
Python 2, str on Python 3), but it's probably too late for that now.
At least until Python 2 support is dropped completely.


-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEZs-E%2BVZ-Hnnm_%3D3Mx9XGS-xX9AfZZMEkAbWukhJf9yk0nvmw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Michael Manfre]

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. Data only migrations would still
>> technically be possible without the ability to alter the schema, but I'm
>> not sure if that functionality would be as useful by itself.
>>
>
> I would say "yes", if something wants to claim to be a fully-supported
> Django backend. In this day and age being able to alter the schema is
> something that a framework/ORM should be providing, IMO.
>

The only backends that can ever claim "fully-supported" are those included
in Django. All other backends rely upon Django internals that can, and do
change in backwards incompatible ways.

There is a difference between the framework providing a feature and a
feature being useful/required for a project/environment. E.g. GIS, template
engine, or if we want to stick to just the ORM features, select related,
distinct on, etc.

The follow up question is, if a backend doesn't support schema alterations,
should Django stop it from working? This would go against the common mantra
of "we won't include it in Django, but we'll make it possible."


 I think it's okay to require SchemaEditor to exist with minimal
>> functionality. It would be ideal if this minimal SchemaEditor was provided.
>> Disabling the alterations with a DatabaseFeature would make the existing
>> BaseDatabaseSchemaEditor on par with BaseDatabaseCreation's ability to
>> create/delete schema objects.
>>
>
> When you say "provided", what do you mean? The current base SchemaEditor
> provides a lot and once we've fixed up some of the issues you raised with
> the MSSQL patch it should be a lot better, certainly within reason to
> inherit it and just set the alteration stuff to NotImplementedError.
>

I prefer having an explicit DatabaseFeature to disable alterations. With
that feature, the base SchemaEditor could check that feature to either noop
or raise NotImplementedError for the alterations. Requiring a backend to
both set the feature and then noop/raise all of the methods controlled by
the feature seems redundant.


Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvT6rK_ZMz5fFh2d261X%2BsSB5KA4_XpBYwt7dW%3DdSh6dg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Ramiro Morales]

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:58 PM, Henrique Romano  wrote:
>
> On Wed, Jan 22, 2014 at 2:38 PM, Shai Berger  wrote:
>> You might want to take this up with django-cms.
>
> Not exactly true.  Even though my problem was with django-cms, if you grep 
> django source code for "LANGUAGES"  you will find this templatetag:
>
> # templatetags/i18n.py
>  15 class GetAvailableLanguagesNode(Node):
>  16 def __init__(self, variable):
>  17 self.variable = variable
>  18
>  19 def render(self, context):
>  20 from django.conf import settings
>  21 context[self.variable] = [(k, translation.ugettext(v)) for k, v 
> in settings.LANGUAGES]
>  22 return ''
>
>  It is also translating the given language name.

Yes, I think that what both pieces of code are doing there is assume
the LANGUAGES setting in effect is the one shipped with Django where:

- All the original language names are in English (covered by ASCII)
- Most of them are translated by the Django translators and shipped
with Django 
(https://github.com/django/django/blob/master/django/conf/locale/en/LC_MESSAGES/django.po#L16)
so translations are readily available.

So it's relying on the fact there there is no need to go outside ASCII
when working with original language names.

I think you are onto something re: the fact that we don't make clear
that our ugettext*() functions fail to accept encoded literals with
characters outside ASCII under Python 2.x. even when the encoding
metadata is correct.

My theory is that the facts that documentation is a bit unclear about
the requirements these source strings arguments should comply with (or
rather, what are the data types supported by these functions) and that
using another language than English as translate-from language doesn't
seem like a common setup have contributed to this not getting too much
visibility until now.

In Python 3 (3.3) this problem doesn seem to exist. See tests below.

> My suggestion is to update the documentation saying that the developer should 
> use ugettext_lazy for the language name if they want it translated

We have something along these lines. See (last two bullets)
https://docs.djangoproject.com/en/1.6/topics/i18n/translation/#how-django-discovers-language-preference

> *or* at least use a unicode string.

I will try to get some feedback from some more experienced devs to if
there is anything to be done about this in code and/or docs.


$ cat a.py
#  -*- coding: utf-8 -*-

import sys
from django.utils.translation import ugettext, ugettext_lazy, ugettext_noop

print("Python version: %s" % sys.version)

a = ugettext_noop("Portugués")

print(a)
print(type(a))
b = u'%s' % a # try to get the lazy placeholder to evaluate itself.
print(b)
print(type(b))

$ file a.py
a.py: Python script, UTF-8 Unicode text executable

PYTHONPATH=.:~/django/upstream
DJANGO_SETTINGS_MODULE=lang_i18n.settings python a.py
Python version: 2.7.3 (default, Sep 26 2013, 20:03:06)
[GCC 4.6.3]
Portugués

Traceback (most recent call last):
  File "a.py", line 12, in 
b = u'%s' % a # try to get the lazy placeholder to evaluate isself.
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
7: ordinal not in range(128)


$ PYTHONPATH=.:~/django/upstream
DJANGO_SETTINGS_MODULE=lang_i18n.settings python3.3 a.py
Python version: 3.3.3 (default, Dec 27 2013, 19:27:19)
[GCC 4.6.3]
Portugués

Portugués



Thanks!

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO7PdF_9%3Dxp0SCkwzmM-rRDTE7X4Yn_UhDaFUuecKSw29jXXZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Andrew Godwin]

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 without the ability to alter the schema, but I'm
> not sure if that functionality would be as useful by itself.
>

I would say "yes", if something wants to claim to be a fully-supported
Django backend. In this day and age being able to alter the schema is
something that a framework/ORM should be providing, IMO.


> 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. I think
> it is reasonable to require any backend to support that portion of
> SchemaEditor.
>
> I think we should have a property on DatabaseFeature that sniffs
> SchemaEditor to figure out whether it supports alterations. That would let
> us use the existing database feature decorators to skip tests.
>

I'm not sure if sniffing is the correct way, but I agree we should have
either that or a direct attribute on Features that can say if a backend
supports certain operations (we already have this to some extent with parts
of SchemaEditor, with things like supports_foreign_keys), and then we can
skip tests based on those.


> I'm not sure I like this generic plan, but I don't have all of the details
> and the discussion can be deferred until a later date. There is some value
> in having a distinction between something that creates just the databases
> (or files) and something that creates the schema inside of the databases.
>

I wouldn't mind keeping actual database creation separate - it doesn't
really belong in SchemaEditor and is mostly used for SQLite and testing
anyway - but the bits of DatabaseCreation that make tables have to go.


> Other than time constraints, is there a reason not to update
> DatabaseCreation in Django 1.7 so that is little more than a proxy to
> SchemaEditor for the create/delete sql? I think we all agree that any
> database backend must be able to create/delete the schema, so I don't think
> it makes much of a difference whether that happens in DatabaseCreation or
> SchemaEditor. All of the database backend API has been deemed internal API
> on several occasions, so it should be safe to make this sort of change and
> also not necessarily be subject to the alpha feature freeze. I'd be happy
> to work on this.
>

It's just time constraints. While that API is technically private, some
things use it and I've done a lot of deep changes as it is without diving
in there and possibly introducing backwards-incompatible code (we'd lose
the syntax highlighted SQL too for command line output but that's not a
massive loss, and should be done by e.g. pygments anyway). There's several
bits in there and introspection that are only around because removing them
was too much of an ask to do in the same release we add all the new stuff.
I do need to stick a PendingDeprecationWarning on it though.


> I think it's okay to require SchemaEditor to exist with minimal
> functionality. It would be ideal if this minimal SchemaEditor was provided.
> Disabling the alterations with a DatabaseFeature would make the existing
> BaseDatabaseSchemaEditor on par with BaseDatabaseCreation's ability to
> create/delete schema objects.
>

When you say "provided", what do you mean? The current base SchemaEditor
provides a lot and once we've fixed up some of the issues you raised with
the MSSQL patch it should be a lot better, certainly within reason to
inherit it and just set the alteration stuff to NotImplementedError.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uq79C9Nqybfkp%2By9QDj4XvOnAXTE1ipUmWMBF_9ZT6wEw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Shai Berger]

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; I think TEST_CREATE should be provided by the test runner, 
so that it's available for all backends. It can be useful for a whole set of 
situations, not just a dysfunctional backend.

(but that's a little off topic, I know).

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401221922.01922.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Shai Berger]

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 not.
> > 
> > You might want to take this up with django-cms.
> 
> Not exactly true.  Even though my problem was with django-cms, if you grep
> django source code for "LANGUAGES"  you will find this templatetag:
> 
> # templatetags/i18n.py
>  15 class GetAvailableLanguagesNode(Node):
>  16 def __init__(self, variable):
>  17 self.variable = variable
>  18
>  19 def render(self, context):
>  20 from django.conf import settings
>  21 context[self.variable] = [(k, translation.ugettext(v)) for k, v
> in settings.LANGUAGES]
>  22 return ''
> 
>  It is also translating the given language name.

You are right. Further, the documentation[1] specifically says that language 
names get translated, whether or not you use this tag.

>  My suggestion is to
> update the documentation saying that the developer should use ugettext_lazy
> for the language name if they want it translated *or* at least use a
> unicode string.

That's not accurate -- the documentation should say that language names get 
translated whether or not you use ugettext_lazy, if you use RequestContext or 
the i18n tags, and *recommend* that anything you put there be either 
translated with ugettext_lazy or be a unicode ubject. It is still valid to use 
a non-unicode string if:

1) The value is all ASCII
2) The value has translations in all used languages.

(you saw the error because your language name does not have a translation, and 
thus was used as given instead).

Bugs and patches welcome,

Shai.

[1] https://docs.djangoproject.com/en/dev/topics/i18n/translation/#other-tags

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401221915.45177.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Michael Manfre]

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, so the backend
> is not the place to say if you want migrations or not.
>

I've been using migrations to refer to migrations and the the schema
alterations done by SchemaEditor since migrations depend on SchemaEditor
being able to do the alterations it wants. I'll try to respect the
distinction going forward to avoid confusion.

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 without the ability to alter the schema, but I'm
not sure if that functionality would be as useful by itself.

 - There is some merit to the ability to turn off migrations on a
> per-backend basis, via a DATABASES setting, but bear in mind that routers
> already let you do this (with the allow_migrate method). The only extra
> thing it would achieve is not having Django record migrations in the
> django_migrations table, but it also looks like it would be useful for
> tests if you hadn't written that part yet.
>
>  - I feel like a DB backend should at least implement SchemaEditor even if
> it returns NotImplementedError for most of the endpoints; even in the
> weirdest relational system, you can still manage create/delete model
> without too much difficulty.
>

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. I think
it is reasonable to require any backend to support that portion of
SchemaEditor.

I think we should have a property on DatabaseFeature that sniffs
SchemaEditor to figure out whether it supports alterations. That would let
us use the existing database feature decorators to skip tests.

 - Bear in mind that the plan is to remove DatabaseCreation entirely in
> favour of SchemaEditor in a few releases' time (and backends are more than
> welcome to make DatabaseCreation use SchemaEditor behind the scenes if they
> want), so at that point if you don't implement it the backend is only ever
> good for querying, which to me feels like an incomplete backend.
>

I'm not sure I like this generic plan, but I don't have all of the details
and the discussion can be deferred until a later date. There is some value
in having a distinction between something that creates just the databases
(or files) and something that creates the schema inside of the databases.

Other than time constraints, is there a reason not to update
DatabaseCreation in Django 1.7 so that is little more than a proxy to
SchemaEditor for the create/delete sql? I think we all agree that any
database backend must be able to create/delete the schema, so I don't think
it makes much of a difference whether that happens in DatabaseCreation or
SchemaEditor. All of the database backend API has been deemed internal API
on several occasions, so it should be safe to make this sort of change and
also not necessarily be subject to the alpha feature freeze. I'd be happy
to work on this.



>  - I'm not sure what the future of ./manage.py sqlall is, but it's going
> to have to be ported to SchemaEditor in future anyway, so it's only useful
> in the transition.
>
> Looking at the discussion, I think the best thing to do is:
>
>  - Make the schema and migrations test skip if connection.schema_editor()
> raises a NotImplementedError (not too hard, we can implement
> connection.has_schema_editor as a boolean to switch on)
>
 - Provide some way to skip the "creating models" part of test setup, so
> SchemaEditor is never needed during it
>

I think it's okay to require SchemaEditor to exist with minimal
functionality. It would be ideal if this minimal SchemaEditor was provided.
Disabling the alterations with a DatabaseFeature would make the existing
BaseDatabaseSchemaEditor on par with BaseDatabaseCreation's ability to
create/delete schema objects.


> I still think all the current third-party backends should be able to
> provide a partial SchemaEditor implementation though, as at minimum they
> all have the DatabaseCreation code in place to make new models. Bear in
> mind that the ./manage.py sqlmigrate command lets you turn migrations into
> SQL scripts to send to your DBA (and many DBAs appreciate having some SQL
> they can work from - I know ours do), so having the ability to make that
> SQL is useful even if Django never runs it.
>

Agreed. DBAs are happier to have a non-blank starting point.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To 

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Henrique Romano]

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 true.  Even though my problem was with django-cms, if you grep
django source code for "LANGUAGES"  you will find this templatetag:

# templatetags/i18n.py
 15 class GetAvailableLanguagesNode(Node):
 16 def __init__(self, variable):
 17 self.variable = variable
 18
 19 def render(self, context):
 20 from django.conf import settings
 21 context[self.variable] = [(k, translation.ugettext(v)) for k, v
in settings.LANGUAGES]
 22 return ''

 It is also translating the given language name.  My suggestion is to
update the documentation saying that the developer should use ugettext_lazy
for the language name if they want it translated *or* at least use a
unicode string.

-- 
Henrique Romano

In the face of ambiguity, refuse the temptation to guess.
-- Tim Peters

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHudJ3%2B8tRpiEn_-%3DmnHOE1dOXXHVNzvhTEW4jOGQrmBxTqg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Henrique Romano]

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_ use a unicode string for the language name. ... What do you guys
> think about making it clear that the user should always use an unicode
> string for the LANGUAGES setting?" conclusion.
>
> Some questions:
>
> - What are you trying to do? Reducing the choics in the LANGUAGES setting?
> Do you intend to translate them from Portuguese to other laguages?
>

I'm using django-cms, I want to support only two languages in my system:
English and Portuguese.

- Why are you using gettext() at the module level? You should use
> ugettext_lazy() or ugettex_noop()
>

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.

- Why did you show us a python interactive session instead of a Python
> soruce code file? How do you thing the interpreter can deduce the encoding
> of a bare string in that case?
>

I didn't care about the correct encoding, I used the interactive session
just to show that a _unicode_ string is necessary for ugettext.


> - Why in both cases are you using Django without are for setting up the
> settings infrastructure first?
>
> - Is the foofoo.py file are you (or rather you text editor) actually using
> the utf-8 encoding?
>
> Yes.

You link to the development documentation but the tests I performed below
> are against the latest 1.6.x stable branch code with Python 2.7.3 (another
> piece of information you don't give us):
>
> $ django-admin.py startproject lang_i18n
> $ cd lang_i18n/
> $ cat foofoo.py
> #  -*- coding: utf-8 -*-
>
> from django.utils.translation import ugettext, ugettext_lazy, ugettext_noop
>
> print(ugettext_lazy("Portugués"))
>
> $ file foofoo.py
> foofoo.py: Python script, UTF-8 Unicode text executable
>
> ramiro@mang:~/dtest/lang_i18n$ DJANGO_SETTINGS_MODULE=lang_i18n.settings
> python foofoo.py
> 
>
So the (lazy)  translation machinery is working.
>

As I wrote above, it "works" because it is returning a functional.proxy
object, if you try to print this object as string, you will see the same
error.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHud%2BDqchJmji7rzNeD3nebLeavArnWDhXNtXNA1KfYNkJBA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Shai Berger]

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
> > 
> > LANGUAGES = (('pt_BR', "Português"),)
> > 
> > If it is the former, then this is a generic issue of translatable strings
> > --
> > nothing to do with settings.LANGUAGES. It is usually assumed that, if you
> > are
> > making a string translatable, you write it in English -- then it's ASCII
> > and
> > all's well.
> > 
> > If it is the latter, please provide more details about the specific error
> > you
> > encountered (stack traces etc).
> 
> > In my test, LANGUAGES is defined as follows:
> LANGUAGES = [
> ('en-us', 'English'),
> ('pt-br', 'Português'),
> ]
> 
> As the documentation didn't make it clear that the language names should be
> unicode, I just used the translated name ("Português") in a plain string, I
> thought it would be OK since settings.py has the encoding declared at the
> top of the file.
> 
> As for the error, it happened inside django-cms.  There's a code that is
> called for building a list of the languages enabled and their names:
> 
> # cms/utils/i18n.py
>  19 def get_languages(site_id=None):
>  20 site_id = get_site(site_id)
>  21 result = get_cms_setting('LANGUAGES').get(site_id)
>  22 if not result:
>  23 result = []
>  24 defaults = get_cms_setting('LANGUAGES').get('default', {})
>  25 for code, name in settings.LANGUAGES:
>  26 lang = {'code': code, 'name': _(name)}
>  27 lang.update(defaults)
>  28 result.append(lang)
>  29 get_cms_setting('LANGUAGES')[site_id] = result
>  30 return result
> 
> In the code above it is trying to translate the language name and it is
> resulting in an error since the name isn't an unicode string.  I understand
> that this is happening in django-cms, but I still think it is relevant to
> document either that the name should be a unicode string or at least the
> english name of the language.

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.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401221838.24696.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Henrique Romano]

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 issue of translatable strings
> --
> nothing to do with settings.LANGUAGES. It is usually assumed that, if you
> are
> making a string translatable, you write it in English -- then it's ASCII
> and
> all's well.
>
> If it is the latter, please provide more details about the specific error
> you
> encountered (stack traces etc).
>
> In my test, LANGUAGES is defined as follows:

LANGUAGES = [
('en-us', 'English'),
('pt-br', 'Português'),
]

As the documentation didn't make it clear that the language names should be
unicode, I just used the translated name ("Português") in a plain string, I
thought it would be OK since settings.py has the encoding declared at the
top of the file.

As for the error, it happened inside django-cms.  There's a code that is
called for building a list of the languages enabled and their names:

# cms/utils/i18n.py
 19 def get_languages(site_id=None):
 20 site_id = get_site(site_id)
 21 result = get_cms_setting('LANGUAGES').get(site_id)
 22 if not result:
 23 result = []
 24 defaults = get_cms_setting('LANGUAGES').get('default', {})
 25 for code, name in settings.LANGUAGES:
 26 lang = {'code': code, 'name': _(name)}
 27 lang.update(defaults)
 28 result.append(lang)
 29 get_cms_setting('LANGUAGES')[site_id] = result
 30 return result

In the code above it is trying to translate the language name and it is
resulting in an error since the name isn't an unicode string.  I understand
that this is happening in django-cms, but I still think it is relevant to
document either that the name should be a unicode string or at least the
english name of the language.

-- 
Henrique Romano

In the face of ambiguity, refuse the temptation to guess.
-- Tim Peters

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHudJe91RoJoGBV14u49zW_h70v6drf336giyWA-Zh%3DGMHsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Shai Berger]

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 untranslated string s it returns unicode(s). You can get the
> > same error by writing
> > 
> > unicode("Português")
> 
> Correct.
> 
> > You should make sure that every string you pass to unicode(), directly or
> > indirectly, is either a unicode object or an ASCII-only string (except in
> > cases where you also pass the encoding); but that is general Python, not
> > Django-specific.
> 
> The point is that I didn't know I had to pass an unicode string, I didn't
> even know about the internals (of django-cms or django, I don't remember)
> where the language name is being translated and therefore an unicode string
> was necessary.  That's what I'm suggesting here, to make it explicit that
> the language name string must be a unicode string.

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 issue of translatable strings -- 
nothing to do with settings.LANGUAGES. It is usually assumed that, if you are 
making a string translatable, you write it in English -- then it's ASCII and 
all's well.

If it is the latter, please provide more details about the specific error you 
encountered (stack traces etc).

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401221816.59089.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Henrique Romano]

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 by writing
>
> unicode("Português")
>

Correct.


> You should make sure that every string you pass to unicode(), directly or
> indirectly, is either a unicode object or an ASCII-only string (except in
> cases where you also pass the encoding); but that is general Python, not
> Django-specific.
>

The point is that I didn't know I had to pass an unicode string, I didn't
even know about the internals (of django-cms or django, I don't remember)
where the language name is being translated and therefore an unicode string
was necessary.  That's what I'm suggesting here, to make it explicit that
the language name string must be a unicode string.

-- 
Henrique Romano

In the face of ambiguity, refuse the temptation to guess.
-- Tim Peters

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHud%2BVhKELjNt-TL1zL5smiszXTMe5LGQ2TFODJWC9Efe%3Dpw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[gilberto dos santos alves]

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" will be automatically handled.
>>
>>
> Can you just try what I reported?  For example:
>
> $ cat ~/foofoo.py
> # -*- coding: utf-8 -*-
> from django.utils.translation import ugettext
>
> print ugettext("Português")
> $ python ~/foofoo.py
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
> ordinal not in range(128)
>
> So, I'm not sure what you are talking about.
> --
> Henrique Romano
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BEHudKiJcgLQg-K2pwQrBFFcCTr%2BpV_t9VqmkSo%3D6n-6Kjqaw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAP9G-NLgyqk%2ByUtSaZ6ueTbLiFfb2xLVCrT8n2Si7%3DgxKE626A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Ramiro Morales]

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" will be automatically handled.
>>
>>
> Can you just try what I reported?  For example:
>
> $ cat ~/foofoo.py
> # -*- coding: utf-8 -*-
> from django.utils.translation import ugettext
>
> print ugettext("Português")
> $ python ~/foofoo.py
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
> ordinal not in range(128)
>
> So, I'm not sure what you are talking about.
>

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_ use a unicode string for the language name. ... What do you guys
think about making it clear that the user should always use an unicode
string for the LANGUAGES setting?" conclusion.

Some questions:

- What are you trying to do? Reducing the choics in the LANGUAGES setting?
Do you intend to translate them from Portuguese to other laguages?

- Why are you using gettext() at the module level? You should use
ugettext_lazy() or ugettex_noop()

- Why did you show us a python interactive session instead of a Python
soruce code file? How do you thing the interpreter can deduce the encoding
of a bare string in that case?

- Why in both cases are you using Django without are for setting up the
settings infrastructure first?

- Is the foofoo.py file are you (or rather you text editor) actually using
the utf-8 encoding?

You link to the development documentation but the tests I performed below
are against the latest 1.6.x stable branch code with Python 2.7.3 (another
piece of information you don't give us):

$ django-admin.py startproject lang_i18n
$ cd lang_i18n/
$ cat foofoo.py
#  -*- coding: utf-8 -*-

from django.utils.translation import ugettext, ugettext_lazy, ugettext_noop

print(ugettext_lazy("Portugués"))

$ file foofoo.py
foofoo.py: Python script, UTF-8 Unicode text executable

ramiro@mang:~/dtest/lang_i18n$ DJANGO_SETTINGS_MODULE=lang_i18n.settings
python foofoo.py


So the (lazy)  translation machinery is working.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO7PdF9NgfG35MvJ5X24M7cSb%3DuOmZLkgkR9250DuT7ESCZO%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Shai Berger]

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 "português" will be automatically handled.
> 
> Can you just try what I reported?  For example:
> 
> $ cat ~/foofoo.py
> # -*- coding: utf-8 -*-
> from django.utils.translation import ugettext
> 
> print ugettext("Português")
> $ python ~/foofoo.py
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
> ordinal not in range(128)
> 
> So, I'm not sure what you are talking about.

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 by writing

unicode("Português")

You should make sure that every string you pass to unicode(), directly or 
indirectly, is either a unicode object or an ASCII-only string (except in 
cases where you also pass the encoding); but that is general Python, not 
Django-specific.

As far as file headers are concerned, you may want to use

from __future__ import unicode_literals

which really does make all your strings unicode.

Please take further discussion of this to django-users or other forums.

HTH,
Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401221639.43305.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[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" will be automatically handled.
>
>
Can you just try what I reported?  For example:

$ cat ~/foofoo.py
# -*- coding: utf-8 -*-
from django.utils.translation import ugettext

print ugettext("Português")
$ python ~/foofoo.py
Traceback (most recent call last):
...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
ordinal not in range(128)

So, I'm not sure what you are talking about.
-- 
Henrique Romano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHudKiJcgLQg-K2pwQrBFFcCTr%2BpV_t9VqmkSo%3D6n-6Kjqaw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[gilberto dos santos alves]

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, 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 -*-
>>
>>
> Specyfing the encoding of the file don't make strings unicode
> automatically, therefore doing it won't solve the problem.  I think the
> problem is still relevant.
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BEHudJHqD4w%2B3ByRq8v4Mu6wbQ2DR0LqvNOJUyLfU_V8fZkGA%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAP9G-NLpjBRfs83NvQ3gCYtD2NuR6Ye8DgHbKd%2B0OynGM3RXAw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

[Henrique Romano]

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 -*-
>
>
Specyfing the encoding of the file don't make strings unicode
automatically, therefore doing it won't solve the problem.  I think the
problem is still relevant.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHudJHqD4w%2B3ByRq8v4Mu6wbQ2DR0LqvNOJUyLfU_V8fZkGA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Andrew Godwin]

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 not.

 - There is some merit to the ability to turn off migrations on a
per-backend basis, via a DATABASES setting, but bear in mind that routers
already let you do this (with the allow_migrate method). The only extra
thing it would achieve is not having Django record migrations in the
django_migrations table, but it also looks like it would be useful for
tests if you hadn't written that part yet.

 - I feel like a DB backend should at least implement SchemaEditor even if
it returns NotImplementedError for most of the endpoints; even in the
weirdest relational system, you can still manage create/delete model
without too much difficulty.

 - Bear in mind that the plan is to remove DatabaseCreation entirely in
favour of SchemaEditor in a few releases' time (and backends are more than
welcome to make DatabaseCreation use SchemaEditor behind the scenes if they
want), so at that point if you don't implement it the backend is only ever
good for querying, which to me feels like an incomplete backend.

 - I'm not sure what the future of ./manage.py sqlall is, but it's going to
have to be ported to SchemaEditor in future anyway, so it's only useful in
the transition.

Looking at the discussion, I think the best thing to do is:

 - Make the schema and migrations test skip if connection.schema_editor()
raises a NotImplementedError (not too hard, we can implement
connection.has_schema_editor as a boolean to switch on)
 - Provide some way to skip the "creating models" part of test setup, so
SchemaEditor is never needed during it

I still think all the current third-party backends should be able to
provide a partial SchemaEditor implementation though, as at minimum they
all have the DatabaseCreation code in place to make new models. Bear in
mind that the ./manage.py sqlmigrate command lets you turn migrations into
SQL scripts to send to your DBA (and many DBAs appreciate having some SQL
they can work from - I know ours do), so having the ability to make that
SQL is useful even if Django never runs it.

Andrew


On Wed, Jan 22, 2014 at 10:10 AM, Shai Berger  wrote:

> 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 allow you to say exactly which schema to use for
> > > testing, and whether or not you want it created. If this is made more
> > > general, then testing can be made to not depend on migrations;  with no
> > > migrations, you will need to take care of the test database yourself --
> > > just like you take care of the production database.
> > >
> > > For Django's own test-suite, tests which need migrations can even be
> > > automatically skipped if getting a schema_editor raises a
> > > NotImplementedError; allowing a backend to easily (well, relatively
> > > easily) pass the suite without implementing migrations.
> >
> > This last bit is the critical part. At present, we don't have any
> > infrastructure to allow tests to be skipped because of a lack of
> migration
> > support. All Django's officially supported backends support migrations,
> so
> > there hasn't been any need to skip any tests.
> >
> > The question is whether we should allow for this for third party
> backends.
> >
> > Historically, the test for a "Django 1.X supported backend" has been
> > "Passes the Django 1.X test suite without errors."; database features
> have
> > been added to allow checking for specific known problems on specific
> > backends (vendor-specific index name size limits, for example), but not
> for
> > entire features. The proposal here is to provide a similar flag for
> > migrations, enabled for all the builtin backends, so that you could have
> a
> > "compliant" 1.7 database backend without supporting migrations. I'd argue
> > this isn't something we want to encourage.
> >
> I agree -- it wasn't my intention to mark such backends as fully supported,
> but as "supported with a caveat".
>
> However, I do think the ability to say "I've got this half of the
> functionality covered" is important. Further, since the DML part of SQL is
> much more consistently implemented than the DDL part, the part without
> migrations is a lot easier to implement than the migrations; the validation
> should be pretty encouraging for 3rd-party backends.
>
> So, I  rephrase my suggestion for the Django tests:
>
>   For Django's own test-suite, tests which need migrations can be
>   automatically skipped if Russell's suggested "no migrations" DATABASES
>   

Re: Must a Django Database Support Migrations?

[Shai Berger]

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 allow you to say exactly which schema to use for
> > testing, and whether or not you want it created. If this is made more
> > general, then testing can be made to not depend on migrations;  with no
> > migrations, you will need to take care of the test database yourself --
> > just like you take care of the production database.
> > 
> > For Django's own test-suite, tests which need migrations can even be
> > automatically skipped if getting a schema_editor raises a
> > NotImplementedError; allowing a backend to easily (well, relatively
> > easily) pass the suite without implementing migrations.
> 
> This last bit is the critical part. At present, we don't have any
> infrastructure to allow tests to be skipped because of a lack of migration
> support. All Django's officially supported backends support migrations, so
> there hasn't been any need to skip any tests.
> 
> The question is whether we should allow for this for third party backends.
> 
> Historically, the test for a "Django 1.X supported backend" has been
> "Passes the Django 1.X test suite without errors."; database features have
> been added to allow checking for specific known problems on specific
> backends (vendor-specific index name size limits, for example), but not for
> entire features. The proposal here is to provide a similar flag for
> migrations, enabled for all the builtin backends, so that you could have a
> "compliant" 1.7 database backend without supporting migrations. I'd argue
> this isn't something we want to encourage.
> 
I agree -- it wasn't my intention to mark such backends as fully supported, 
but as "supported with a caveat". 

However, I do think the ability to say "I've got this half of the 
functionality covered" is important. Further, since the DML part of SQL is 
much more consistently implemented than the DDL part, the part without 
migrations is a lot easier to implement than the migrations; the validation 
should be pretty encouraging for 3rd-party backends.

So, I  rephrase my suggestion for the Django tests:

  For Django's own test-suite, tests which need migrations can be
  automatically skipped if Russell's suggested "no migrations" DATABASES
  setting is set; allowing a backend to easily validate its migration-less
  part.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33933764.nuWK3GA93E%40deblack.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Aymeric Augustin]

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 may fall behind.

For your production use case, you could get away with `./manage.py
sqlall` which is unchanged in 1.7. That will give you a new  schema
you can diff with the current schema.

If I understand your point regarding Django's test suite, it doesn't
even start because it uses the migration API to create the tables.
You could probably solve that with a custom test runner that
overrides table creation, basically to pipe the output of `sqlall` to
the database. That area of the code base isn't particularly complex.
Let's discuss on IRC if you need pointers.

Assuming this workaround provides a short term solution, it may be
bundled with the database backends that need it. I think that would
be good enough. I share Russell's concern about endorsing a partial
solution.

I hope this helps,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mVtj%2BRw712pMDXwR7i0V%2BkFjOia3_huSkWAHheDvgbP7g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Must a Django Database Support Migrations?

[Russell Keith-Magee]

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 schema migrations or want Django to manage the
> > > migrations. My primary project has Django working against a legacy
> > > database and relies upon an external tool (and a DBA) to manage schema
> > > changes in our environment. This workflow uses syncdb to create the
> tables
> > > in to a temporary database and then compares it will an external tool
> that
> > > generates an SQL diff. This diff is tested by the DBA before being
> applied
> > > to the production database. This basic workflow will continue even
> after
> > > upgrading to Django 1.7.
> > >
> > > This scenario does not necessarily need to be handled as a database
> > > feature. Russell's idea during the IRC discussion was a database
> > > configuration that acts as a safety to prevent migrations from being
> > > applied; similar to managed models.
> >
> > I have no problem with this use case. My problem with the specific
> proposal
> > in #21841 is that the database backend is the wrong place to be making
> this
> > distinction. The decision as to whether the backend supports migrations
> is
> > independent of whether the user wants to use them. The PostgreSQL
> supports
> > migrations; that doesn't mean I want to use them.
> >
> > If model-level Meta.managed isn't enough to disable migrations, then a
> > settings.DATABASES flag may be called for, but that's different to what
> was
> > originally proposed.
> >
>
> I was going to say that the argument confuses the backend level with the
> project level. Russell beat me to it :)
>
> > > 2) NoSQL databases don't necessarily have an enforced schema. What
> would
> > > migration mean for NoSQL? Would it noop or attempt to update existing
> > > data? Do we even care because NoSQL is not officially supported by
> Django?
> >
> > This is a problem that we don't have (since we don't support NoSQL), so
> the
> > question is completely hypothetical. However, I don't have any difficulty
> > believing that the *concept* of migrations could exist on NoSQL
> databases -
> > the implementation just won't look anything like "ALTER TABLE ADD
> COLUMN".
> >
>
> +1 Russell, again.
>
> > 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 use mysql despite
> its
> > > many faults, so anything is possible.
> >
> > This one, which seems unlikely.
>
> Actually, SQLite "doesn't support altering the schema in a way that would
> work
> with Django's schema migrations API". The SQLite backend bends over
> backwards
> to comply; its implementation of "alter column" is "recreate the table,
> copying the data". AFAIK it doesn't quite get everything right, even with
> the
> somersaults it pulls; and yet, it's close enough for comfort.
>
> So, in order to really count as "can't support", a backend needs to be
> crippled to a level where implementing django-1.6-syncdb is probably
> impossible as well.
>
> >
> > There's also option 4: The developer of a particular backend doesn't have
> > the time or inclination to add support for migrations.
> >
>
> which brings me back to
>
> > > Database backend compliance is defined by its ability to pass Django's
> > > test suite. A fully compliant database can pass 100% of tests dealing
> with
> > > the database. If a database backend raises NotImplementedError for
> > > schema_editor, it is currently 0% compliant because it cannot create
> the
> > > database tables.
> > >
> > > If database backends are not required to support migrations, then there
> > > would need to be some form of fallback behavior to provide a Django 1.6
> > > syncdb-esque behavior. It would create the schema without attempting
> > > alterations.
> > >
>
> and
>
> > > *Potential Issues With Optional Support*
> > >
> > > 2) Currently unknown level of effort or complexity to allow the
> migrations
> > > to fallback to a Django 1.6 syncdb-esque behavior.
>
> An alternative, which I think will have much lower costs, and send the
> right
> message about such backends is:
>
> A) Django only changes the schema through migrations; if you don't want
> migrations in your backend or your project, than the schema changes need to
> happen some other way, using an external tool.
>
> 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 allow you to say exactly which schema to use for testing, and
> whether or not you want it created. If this is made more general, then
> testing