>>Greg Ewing wrote...
>>Seems to me there shouldn't be changeable default
>>encoding for source files at all. The encoding of
>>a source file is a property of the file itself,
>>not the interpreter used to read it.
>Guido van Rossum wrote...
>But practicality beats purity. Some people don't exchange Python code
>with others, but they use a lot of code they write and maintain
>themselves. It's hard to explain to them the need of repeating the
>encoding in every single module.
This may be naive, but would a package-level encoding specifier be a useful
middle ground? This would adhere to the "purity" of associating the encoding
with the source files, but still provide a less laborious solution (assuming
source files are relatively well-organized in packages)...
Along this line of thought, I would assume the big question would be, "Is it
safe/fair/wise to assume a package's source files are homogenous
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
When you interface const-correct C or C++ code with Python, you
currently need to jump through hoops like this:
somefunc(const char* modulename, const char* key)
... PyImport_ImportModule(const_cast<char*>(modulename)) ...
I'd be willing to invest some time to change this, the question is:
1. someone opposed to such a change?
2. any technical reasons against it (const is ANSI, do we have a
portability problem that cannot be solved by a #define)?
The largest negative effect I can see is that it'll add some turbulence
to the CVS log (many little changes).
aahz(a)pythoncraft.com (Aahz) writes:
> Figured this should be moved.
Probably right. Slightly surprisingly, there doesn't seem to be a
sf support request on this issue -- maybe it's just us?
I'll file one... here:
> ------- start of forwarded message -------
> Newsgroups: comp.lang.python
> From: Michael Hudson <mwh(a)python.net>
> Subject: Re: zlib vulnerabilities and python
> Message-ID: <u8z8wsey5.fsf(a)python.net>
> References: <SASl3IAyAUj8EwS4(a)jessikat.fsnet.co.uk> <a6nnsg$chc$1(a)panix1.panix.com>
> Date: Wed, 13 Mar 2002 14:43:13 GMT
> aahz(a)pythoncraft.com (Aahz) writes:
> > In article <SASl3IAyAUj8EwS4(a)jessikat.fsnet.co.uk>,
> > Robin Becker <robin(a)jessikat.fsnet.co.uk> wrote:
> >>Does the recent zlib double free vulnerability
> >>impact zlib.pyd?
> > Dunno, but I filed a SF bug to check compatibility with the new 1.1.4.
> But because mail from the sf tracker seems to be hitting the bit
> bucket, noone knows about this.
> Time to look at roundup again? The tracker on sf is starting to piss
> me off (even more).
> We've had a lot of problems going from glibc 2.0 to glibc 2.1.
> People claim binary compatibility. Except for functions they
> don't like. -- Peter Van Eynde, comp.lang.lisp
> ------- end of forwarded message -------
> Python-Dev mailing list
42. You can measure a programmer's perspective by noting his
attitude on the continuing vitality of FORTRAN.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Figured this should be moved.
------- start of forwarded message -------
From: Michael Hudson <mwh(a)python.net>
Subject: Re: zlib vulnerabilities and python
References: <SASl3IAyAUj8EwS4(a)jessikat.fsnet.co.uk> <a6nnsg$chc$1(a)panix1.panix.com>
Date: Wed, 13 Mar 2002 14:43:13 GMT
aahz(a)pythoncraft.com (Aahz) writes:
> In article <SASl3IAyAUj8EwS4(a)jessikat.fsnet.co.uk>,
> Robin Becker <robin(a)jessikat.fsnet.co.uk> wrote:
>>Does the recent zlib double free vulnerability
> Dunno, but I filed a SF bug to check compatibility with the new 1.1.4.
But because mail from the sf tracker seems to be hitting the bit
bucket, noone knows about this.
Time to look at roundup again? The tracker on sf is starting to piss
me off (even more).
We've had a lot of problems going from glibc 2.0 to glibc 2.1.
People claim binary compatibility. Except for functions they
don't like. -- Peter Van Eynde, comp.lang.lisp
------- end of forwarded message -------
I am a Japanese who sent a request to MAL. Let me explain about some
1. I didn't request to make sys.defaultencoding() as default.
This is a part of the mail I sent you.
> 2. "native encoding" specifier
> A special encoding name such as "native" or "defaultencoding"
> that means "to obey sys.defaultencoding()" may helpful. Here in
> Japan, we use two character encodings, ShiftJIS on Windows and
> EUC-JP on various Unix. When we move Python source files among
> these platforms, we usually have to convert the file encoding of
> the source files (just like as you convert CR+LF to LF when you
> move text files from Windows to Unix). Not only tools for
> manual encoding conversion, we also have a patched version of
> CVS to do it automatically. However, if we fix a file encoding
> by a magic comment, the task of encoding conversion will be
> complicated, because we should scan source files and update the
> magic comment when moving the files from one platform to the
> other. If we can use a "defaultencoding" encoding that the
> actual meaning varies among platforms, we can safely convert the
> file encoding without editing the magic comment, so that we can
> use common encoding conversion tools such as nkf(1), ack(1) and
> the patched version of CVS.
What I wanted is "special encoding name" that refers to sys.defaultencoding().
But, as I told to MAL, I changed my mind because I found I can create
new special codec to do this, and it's pretty easy.
I'm sorry for late for sending mail about misapprehension, but I'm not
on this list and I didn't know this until today. It is easier for me and
other Japanese to join discussion if you move this topic to i18n-sig.
(And if you can bear my English. The mail I sent to MAL was translated
to English by Tamito, an author of the JapaneseCodecs).
About default encoding, I agree with ascii.
2. Code conversion is necessary for Japanese programmers.
I think Python core don't have to mention about Japanese specific
issues, because PEP 263 is general enough to support our encodings.
But please don't think that Japanese people are happy with utf-8. Suzuki
wrote that I told we don't need code conversion, but this is not true. I
don't know why he wrote so, and most of us needs native encodings such
as ShiftJIS or EUC-JP.
I put PEP 286, "Enhanced Argument Tuples", on
The main rationale is that PyArg_ParseTuple should be able to attach
additional objects to the argument tuple, so that the application
would not need to deal with the memory allocated in the process of
Any input appreciated,
Hi all, sorry for posting to this list.
I found a (maybe?) new bug, which crashes the interpreter.
Just do this (is't repeatable):
>>> from types import *
>>> mod = ModuleType.__new__(ModuleType)
Upon trying to do a str(mod) to print it (I believe),
the VM crashes and burns.
I was searching for a way to construct a new module
from it's file's compiled bytecode (just read() the "*.pyc" file),
so I thought maybe the ModuleType had some kind of constructor
which could use the compiled byte code.
I don't have web access, so I couldn't post it as a bug
report in sourceforge.
Gustavo Córdova Avila
Å 8351-3861 | 8351-3862
I'm just translating the Python Pocked Reference the
second time, and I stumbled over this:
gives a ValueError: empty separator.
I would expect
as result, since this is the maximum result of undoing
For what reason is this asymmetry?
Christian Tismer :^) <mailto:firstname.lastname@example.org>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net/
14163 Berlin : PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com/