Encoding in models.py (and maybe other files too)

[nsteinmetz]

Hi,

As I use characters with accents, I got the following issue yesterday
when validating my models :

mvmo.cv: Non-ASCII character '\xc3' in file /home/django/mvmo/../mvmo/
cv/models.
py on line 111, but no encoding declared; see http://www.python.org/peps/pep-026
3.html for details (models.py, line 111)

Ok, so with this helpful error message, I could easily find that I had
to add

# -*- coding: utf8 -*-

at the beginning of my file to solve the issue.

So my question is : why is not such a line added by default in
models.py so that such an issue never happens ?

You could have something like for a default models.py :

# -*- coding: <set your encoding here> -*-
from django.db import models

# Create your models here.

Does it make sense ? Is it worth a ticket ? would it be solved by the
unicode branch ?

Regards,
Nicolas


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malcolm Tredinnick]

On Tue, 2007-04-17 at 16:11 +0000, [hidden email] wrote:

> Hi,
>
> As I use characters with accents, I got the following issue yesterday
> when validating my models :
>
> mvmo.cv: Non-ASCII character '\xc3' in file /home/django/mvmo/../mvmo/
> cv/models.
> py on line 111, but no encoding declared; see http://www.python.org/peps/pep-026
> 3.html for details (models.py, line 111)
>
> Ok, so with this helpful error message, I could easily find that I had
> to add
>
> # -*- coding: utf8 -*-
>
> at the beginning of my file to solve the issue.
>
> So my question is : why is not such a line added by default in
> models.py so that such an issue never happens ?

The default encoding may not be utf-8.

> You could have something like for a default models.py :
>
> # -*- coding: <set your encoding here> -*-
> from django.db import models
>
> # Create your models here.
>
> Does it make sense ? Is it worth a ticket ?

I don't think so. It's a line-ball call, though, for sure. See below for
my reasoning.

>  would it be solved by the
> unicode branch ?

Not really -- although in that case there would be slightly more value
in adding the encoding line, since bytestrings that aren't UTF-8 encoded
will break in interesting ways.

My main reason for not adding this: if you forget to add the encoding
line, Python gives you a very clear error message and explains what you
need to do to fix it. Sometimes that alerts you to the fact that you've
accidently included non-ASCII characters (e.g. via cut-and-paste) and
need to actually check the encoding -- such as when you've pasted from a
document in Windows. If we automatically include such a line and it's
wrong for some reason (because you're in Japan and prefer to use
shift-JIS, or you're cursed to use Windows, so CP-1152 is a way of
life), things will sort of work and you'll get an unexpected decoding
error way down the track. As a programmer who makes mistakes, I like the
early warning system a bit better.

Regards,
Malcolm



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[nsteinmetz]

On 18 avr, 05:16, Malcolm Tredinnick <[hidden email]> wrote:

> Not really -- although in that case there would be slightly more value
> in adding the encoding line, since bytestrings that aren't UTF-8 encoded
> will break in interesting ways.
>
> My main reason for not adding this: if you forget to add the encoding
> line, Python gives you a very clear error message and explains what you
> need to do to fix it. Sometimes that alerts you to the fact that you've
> accidently included non-ASCII characters (e.g. via cut-and-paste) and
> need to actually check the encoding -- such as when you've pasted from a
> document in Windows. If we automatically include such a line and it's
> wrong for some reason (because you're in Japan and prefer to use
> shift-JIS, or you're cursed to use Windows, so CP-1152 is a way of
> life), things will sort of work and you'll get an unexpected decoding
> error way down the track. As a programmer who makes mistakes, I like the
> early warning system a bit better.

Ok it makes sense.

Thanks for your reply,
Nicolas


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[ashwoods]

maybe a little off-topic, but why do you need special characters in
code? it makes code maintainance and reusability a bit more difficult,
while there are not really  a lot of situations where its necesary.

just asking :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[nsteinmetz]

On 18 avr, 13:39, ashwoods <[hidden email]> wrote:
> maybe a little off-topic, but why do you need special characters in
> code? it makes code maintainance and reusability a bit more difficult,
> while there are not really  a lot of situations where its necesary.
>
> just asking :)

Because french words has accents, and I need them for some choices
list ;-)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[John Lenton]

On 4/18/07, ashwoods <[hidden email]> wrote:
>
> maybe a little off-topic, but why do you need special characters in
> code? it makes code maintainance and reusability a bit more difficult,
> while there are not really  a lot of situations where its necesary.
>
> just asking :)

I don't know about Nicolas, but I'm writing something for a
Spanish-speaking customer, so I might have a TelephoneField
("teléfono") in there, for example.

--
John Lenton ([hidden email]) -- Random fortune:
The trouble with a lot of self-made men is that they worship their creator.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[kenneth gonsalves]

On 18-Apr-07, at 5:44 PM, John Lenton wrote:

>>
>> just asking :)
>
> I don't know about Nicolas, but I'm writing something for a
> Spanish-speaking customer, so I might have a TelephoneField
> ("teléfono") in there, for example.

the way to do it is verbose_name = _("telephone")

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[atilla-3]

> >> just asking :)
> >
> > I don't know about Nicolas, but I'm writing something for a
> > Spanish-speaking customer, so I might have a TelephoneField
> > ("teléfono") in there, for example.
>
> the way to do it is verbose_name = _("telephone")

Yes, instead of naming your models with "funky" characters, you can
always set the verbose displayed name to whatever you need it to be.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[mamcxyz]

> Yes, instead of naming your models with "funky" characters, you can
> always set the verbose displayed name to whatever you need it to be.

The are not funky. Are the normal characters in each labguage. Anyway,
that show too if the "funky" chars appear in "text" so....


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[atilla-3]

On 18/04/07, mamcxyz <[hidden email]> wrote:
>
> > Yes, instead of naming your models with "funky" characters, you can
> > always set the verbose displayed name to whatever you need it to be.
>
> The are not funky. Are the normal characters in each labguage. Anyway,
> that show too if the "funky" chars appear in "text" so....

Ah, so I've misunderstood what the problem is. I usually try to make
everything in utf-8 from the very beginning, since I've had a lot of
encoding issues in past projects, so when I encounter these errors the
usual suspect is mixing Unicode and non-Unicode strings. As long as
you keep that consistent and set your encoding correct, things will be
pretty much OK. But I have to agree with Malcolm here - adding a
default would just result in people asking the reverse question - "why
does my code break in configuration X?".

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[ashwoods]

ah, i code for english, german, spanish. :)

 but as far as i know, the encoding declaration is only needed if you
have special chars in _code_ as opposed to strings. your strings can
be unicode without having to declare an encoding for the python file.

my opinion is that if you can, you should even choose model names,
function names, etc.. not only without special chars, but also in
english, even more so in the opensource world. the part that the user
"sees" can be translated using verbose name, or I18N.

using english and no funky chars ensures that your code works well for
others too. i always use snippets of code from here or there. just
imagine how much work  and time i would need just to understand the
code if everybody writes code in their language, or if i use other
code as libraries with classes in different encodings...

cheers,
ashley

On Apr 18, 5:03 pm, Atilla <[hidden email]> wrote:

> On 18/04/07, mamcxyz <[hidden email]> wrote:
>
>
>
> > > Yes, instead of naming your models with "funky" characters, you can
> > > always set the verbose displayed name to whatever you need it to be.
>
> > The are not funky. Are the normal characters in each labguage. Anyway,
> > that show too if the "funky" chars appear in "text" so....
>
> Ah, so I've misunderstood what the problem is. I usually try to make
> everything in utf-8 from the very beginning, since I've had a lot of
> encoding issues in past projects, so when I encounter these errors the
> usual suspect is mixing Unicode and non-Unicode strings. As long as
> you keep that consistent and set your encoding correct, things will be
> pretty much OK. But I have to agree with Malcolm here - adding a
> default would just result in people asking the reverse question - "why
> does my code break in configuration X?".

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[nsteinmetz]

On 19 avr, 12:45, ashwoods <[hidden email]> wrote:

> ah, i code for english, german, spanish. :)
>
>  but as far as i know, the encoding declaration is only needed if you
> have special chars in _code_ as opposed to strings. your strings can
> be unicode without having to declare an encoding for the python file.
>
> my opinion is that if you can, you should even choose model names,
> function names, etc.. not only without special chars, but also in
> english, even more so in the opensource world. the part that the user
> "sees" can be translated using verbose name, or I18N.
>
> using english and no funky chars ensures that your code works well for
> others too. i always use snippets of code from here or there. just
> imagine how much work  and time i would need just to understand the
> code if everybody writes code in their language, or if i use other
> code as libraries with classes in different encodings...

I agree on the principle.

In my case, how would you implement this ?

class Civilstate(models.Model):
    CIVILITY_CHOICES = (
         ('single', 'Célibataire'),
         ('taken', 'Marié'),
    )
    who = models.ForeignKey(User, unique=True,
verbose_name='Personne')
    street = models.CharField('Adresse 1', maxlength=100)
    street_bis = models.CharField('Adresse 2', maxlength=100)
    zipcode = models.IntegerField('Code postal', maxlength=5)
    city = models.CharField('Ville', maxlength=100)
    phone = models.CharField('Téléhone', maxlength=20)
    mobile = models.CharField('Portable', maxlength=20)
    civility = models.CharField('Statut matrimonial', maxlength=20,
choices=CIVILITY_CHOICES)
    birthdate = models.DateField('Date de naissance',)
    children = models.IntegerField('Nombre d\'enfants',)

I'm really interested in getting good/best practices :-)

Regards,
Nicolas


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Malcolm Tredinnick]

On Thu, 2007-04-19 at 10:45 +0000, ashwoods wrote:
> ah, i code for english, german, spanish. :)
>
>  but as far as i know, the encoding declaration is only needed if you
> have special chars in _code_ as opposed to strings. your strings can
> be unicode without having to declare an encoding for the python file.

This isn't true. It's even verifiable with a one-line program. Having,
either

        a = '€'

or

        a = u'€'

in your source file will trigger a warning from python if you don't have
an encoding declaration.

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[ashwoods]

ops. my wrong. so the only way to keep it "clean" is using i18n.
might be an overkill for small apps in one languange though.

On Apr 19, 1:46 pm, Malcolm Tredinnick <[hidden email]>
wrote:

> On Thu, 2007-04-19 at 10:45 +0000, ashwoods wrote:
> > ah, i code for english, german, spanish. :)
>
> >  but as far as i know, the encoding declaration is only needed if you
> > have special chars in _code_ as opposed to strings. your strings can
> > be unicode without having to declare an encoding for the python file.
>
> This isn't true. It's even verifiable with a one-line program. Having,
> either
>
>         a = '€'
>
> or
>
>         a = u'€'
>
> in your source file will trigger a warning from python if you don't have
> an encoding declaration.
>
> Regards,
> Malcolm

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---