Proposal: require 7-bit source str's

[Hallvard B Furuseth]

Martin v. Löwis wrote:
>Hallvard B Furuseth wrote:
>> Well, I don't think that's better, but if it's rejected for Python
>> that'll be my next stop.
> 
> I can see how the global warning is provided (which then can be 
> configured into an error through the warnings module). However,
> I don't want to introduce additional magic comments. I already
> dislike the coding declarations for being comments, and would
> have preferred if they had been spelled as
> 
> directive encoding "utf-8"

I can see that.

> The coding declaration was only acceptable because
> - a statement would have to go before the doc string, in
>    which case it would not have been a docstring anymore, and

Hmm...

  >>> def foo():
  ...   """hør"""
  ...   pass
  ... 
  >>> help(foo)
  Help on function foo in module __main__:
  
  foo()
      hør
  
  >>> def bar():
  ...   u"""hør"""
  ...   pass
  ... 
  >>> help(bar)
  >>> help(bar)
  Traceback (most recent call last):
    ...
  UnicodeEncodeError: 'ascii' codec can't encode character '\uf8'
  in position 59: ordinal not in range(128)

Even if the doc string is written in English, it may still need to
use non-English names.

> - there was prior art (Emacs and VIM) for declaring encodings
>    to editors, inside comments
> 
> Your proposed annotation has no prior art. As it has
> effects on the syntax of the language, it should not be in
> a comment.

Well, I think it belongs logically together with the coding
declarations, but I see your point.

Still, how about 'directive str7bit', 'directive -W::str7bitWarning' or
something?

Or '@str7bit' / '@option -W::str7bitWarning', come to think of it.  Like
your 'directive encoding "utf-8"', it affects the parsing of the file.
So I think this is a good time to use a special character, so the
construct will stand out.

And '@decorator_name' would be '@decorator decorator_name', of course.
But I'll go to the other thread with that.

-- 
Hallvard