Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #2270 (closed enhancement: wontfix)

Opened 10 years ago

Last modified 10 years ago

TG2b6's update and the project template's encoding

Reported by: hhsuper Owned by:
Priority: normal Milestone: 2.0rc1
Component: TurboGears Version: trunk
Severity: major Keywords:


yet, tg is update quickly, when i use the b6, i found there isn't 'paster quickstart -e project' and also no 'paster quickstart -elixir', so compare the b6's quickstart.py's history version, found that the trunk is also different, so what? delete that functionality?

another suggestion, when use b6, i found that the paster quickstart generated project file's are all encoding with ascii, i think that use utf-8 is better(tg is for the global,thanks), when i check the trunk, i found that have been added "# -*- coding: utf-8 -*-", it's great, but also should change the file's encoding(which is still ascii) with utf-8 also, or you will got un-confirmed encoding pbl.



ascii.py Download (65 bytes) - added by hhsuper 10 years ago.
utf8.py Download (68 bytes) - added by hhsuper 10 years ago.
encoding_test.rar Download (249 bytes) - added by hhsuper 10 years ago.

Change History

comment:1 Changed 10 years ago by chrisz

  • The Elixir option was removed because nobody wanted to maintain the Elixir support (most developers are using plain SQLAlchemy).
  • Right, the encoding hints have been added. What do you mean with "should change file encoding"? Since they contain only ascii chars, they are already properly encoded. We could add a BOM and/or some arbitrary non-ascii chars, but this will only cause trouble for people or editors who are not accustomed with utf-8, so I don't think it would be a good idea.

Changed 10 years ago by hhsuper

Changed 10 years ago by hhsuper

comment:2 Changed 10 years ago by hhsuper

thanks for the quickly reply

The Elixir's issue is ok

the encoding thing, i have some different thought, if only add encoding hints(utf-8) in file, but the file's actual encoding still the default(ascii),

  1. your encoding will inconsist, you declare your file encoding utf-8 with the hint, but actual your file encoding isn't uft-8,

so you can't input some non-ascii charactors actually, also can't get the utf-8 hint functionality, see the sample below

  1. actually, the simple window's notepad is support for utf-8, i don't think that other editors that don't support utf-8 should be used for the web(or tg)'s dev

(I can't upload the attach correctly)attach has two files, same content, same aim to output the Russia chars 'вгдеё', all with the hint utf-8, but ascii.py's file encoding is ascii, and the utf8.py's file encoding as you guess is utf-8, as you python shell support the utf-8, run the two files, utf8.py get the right result, but ascii.py throw a exc, so you can't use the hint only to get the utf-8's benefit, it's same the tg's project template files, only difference is we output to shell, but tg output to the browser(which support utf-8 affirmly).

comment:3 Changed 10 years ago by hhsuper

the above attach file has some problem, cause they are processed by your server, if could i would send them to you use gmail


Changed 10 years ago by hhsuper

comment:4 Changed 10 years ago by hhsuper

see the rar file encoding_test.rar, it contains the above two files

comment:5 Changed 10 years ago by chrisz

hhsuper, your "ascii.py" file is in fact not ascii encoded, but encoded with windows-936 or something. Obviously you cannot encode a file with ascii that contains non-ascii characters.

The point is that none of our quickstart template files contains any non-ascii characters. So whether you store them as ascii or utf-8 makes no difference, they are both valid ascii files and valid utf-8 files at the same time. What happens when you start entering non-ascii chars and save these files depends solely on the default encoding of your editor (it seems it's windows 936). The only way to enforce UTF-8 would be to add a BOM at the beginning of the file, but some programs or people could have problems with this since it is not very common in the Linux world.

comment:6 Changed 10 years ago by hhsuper

I think it's not the windows or linux matter, mostly our tg based application will deploy on a linux server(that is production server), it will also encounter encoding pbl as our development env, the actual reason is that you have a inconsist application encoding which may cause some problem in future, also you can't get the utf-8's benefits only with declare hint, so what's the effect only with the declare hint?

I think tg is a global based app framework, so I recommand it has a global based usablity, just like you build a international web application you will choose utf-8 in all sides of you app. Even if support a argument for utf-8 is also beautiful, but only the inconsist encoding project template is sth awful, doesn't it?

comment:7 Changed 10 years ago by chrisz

Please be more specific in what exactly you want to be changed and please read my explanations again. There is no inconsistency in any of the TG files, and if you create such inconsistency by saving your own project files in the wrong encoding, there is nothing TG can do about it.

comment:8 Changed 10 years ago by hhsuper

ok, be patient please, I ask a simple question, what's the effect only with the declare hint? only with this you will get the utf-8's benefit? thanks.

comment:9 Changed 10 years ago by chrisz

You actually don't need the encoding hints for the quickstarted project and as long as you only use ascii chars, but they also won't harm in this case.

But once you start using non-ascii chars you will need the encoding hints, so they have been added to spare you some typing. The utf-8 encoding has been chosen since this is what we recommend and most people want to use.

So you can just go ahead, enter your non-ascii chars and save the files. If you editor doesn't save this as utf-8 you should check the configuration of your editor, this has nothing to do with TG.

By adding a UTF-8 BOM at the top of the file, we could theoretically give the editor a broad hint that it should use UTF-8. But this is not yet very common and would cause more harm than use, since many tools don't expect it (e.g. I noticed gettext has problems with BOMs, and some other Unix tools expect the shebang at the exact start of the file) or give warnings that may confuse users.

comment:10 Changed 10 years ago by mramm

  • Status changed from new to closed
  • Resolution set to wontfix

comment:11 Changed 10 years ago by hhsuper

I don't want to prove sth, but the current hint doesn't has any effect, also be used in a incorrect fasion, see the pylons's unicode document  http://wiki.pylonshq.com/display/pylonsdocs/Unicode here, especially the 1.3 Unicode Literals in Python Source Code block.


Note: See TracTickets for help on using tickets.