PEP: Defining Python Source Code Encodings

Roman Suzi rnd at onego.ru
Tue Jul 17 22:51:08 CEST 2001


On Tue, 17 Jul 2001, Bruce Sass wrote:

>
>Python currently manages .pyc and .pyo files by placing them in the
>same location as the .py they are generated from, only if the location
>is not writeable or the program has changed will it get recompiled...
>
>Why not extend this to allow Python to manage .py-s, and allow for set
>locations for source and byte-code; a command option can be used to
>get the old behaviour where .pyc|o live where the source does.

Good idea! But the extention must be called .spy ;-)

><...>
>
>> This will make script-writer happy (no conversion overhead) and those who
>> want to write encoding-enabled programs (they could specify
>> __encodings__.py)
>
>Do you mean: use "import __encodings__" in a program, have an
>__encodings__.py in a modules subdir (as is with __init__.py), or just
>on sys.path?

I donno. I put it to provoke thoughts.

>Allowing for some kind of system and per-user customization seems
>prudent; a __magic__ file both feels natural (Pythonic) and could
>allow for system, program, and per-user settings or tweaks...

>> I have a feeling that PEP is solving non-problem. Or have I lost
>> the thread?
>
>Who ever said a PEP must solve a problem.

:)))))
Is PEP creating a problem?

>> Aren't encodings better confined in documents (in XML for examples),
>> than programs?
>
>I agree, this is document meta-stuff and should be handled as far away
>from the language as possible.  However, Python does need to look at
>documents at some point, so some way of transparently handling
>different encodings (and why not formats) is needed.

"To look at docs" doesn't require "be a doc".

>> If programs need to be written in unicode, then isn't the next step
>> o allow embedding sound, graphics and video?
>> (I imagine video docstring ;-)
>
>cool...
>
># ## format videodocstring
>
>> I can admit that using utf-8 in writing programs could be justified,
>> but Unicode... It will bring nightmare...
>
>...if handled badly.
>
>
>- Bruce
>
>p.s.
>
>Q: How do you handle literate, unicoded source with video docstrings?
>A: .py-s are assumed to be usable without pre-processing, and only
>   the bit of Python that handles the pre-processing determines when
>   a source is actually a source.py.
>
>e.g.,  doing "python source", when `source' contains:
>
>	# ## format noweb
>	# ## format videodocstring
>	# ## encoding utf-8
>
>would result in Python running `source' through the noweb filter to
>separate the code from the docs, then through the videodocstring
>filter to split off the fancy docstrings, and finally doing whatever
>it needs to do to handle the non-standard encoding.  The result would
>be called `source.py' and be stored <somewhere>; the next time Python
>gets handed `source' it can check for <somewhere>/source.py, and
>eschew the conversion steps if they have already been done.

Or, yes! And some dosstrings could be web-cam broadcasts from PythonLabs
;-)

Well, at least some recording must be done.
For example, when Python starts, it shows random piece
from M.P.F.C. show. (When Digicool will buy rights to MPFC?)

Or when user tries to put xrange outside for loop statement,
GvR's voice says: "Oh, no!"

:-)

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Tuesday, July 17, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "...put knot yore trust inn spel chequers." _/





More information about the Python-list mailing list