Mailman 3 March 2002 - Python-Dev

Re: [Python-Dev] PEP 263 considered faulty (for some Japanese)
by Chris Hagner 14 Mar '02

14 Mar '02

>>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 (encoding-wise)?". Chris Hagner __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/

2 1

Opinions on const-correctness?
by j.her＠t-online.de 13 Mar '02

13 Mar '02

Hi! 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). Ciao, Jürgen

10 16

Re: [Python-Dev] SF tracker problems
by Michael Hudson 13 Mar '02

13 Mar '02

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: https://sourceforge.net/tracker/index.php?func=detail&aid=529477&group_id=1… Cheers, M. > ------- 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 > >>http://news.com.com/2100-1001-857008.html > >>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). > > Cheers, > M. > > -- > 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 > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > -- 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

1 0

SF tracker problems
by aahz＠pythoncraft.com 13 Mar '02

13 Mar '02

Figured this should be moved. ------- 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 >>http://news.com.com/2100-1001-857008.html >>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). Cheers, M. -- 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 -------

1 0

Re: PEP 263 - default encoding
by Atsuo Ishimoto 13 Mar '02

13 Mar '02

Hello, I am a Japanese who sent a request to MAL. Let me explain about some issues. 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. Regards, -------------------------- Atsuo Ishimoto ishimoto(a)gembook.org Homepage:http://www.gembook.jp

2 1

PEP 286: Please comment
by Martin v. Loewis 13 Mar '02

13 Mar '02

I put PEP 286, "Enhanced Argument Tuples", on http://python.sourceforge.net/peps/pep-0286.html 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 argument parsing. Any input appreciated, Martin

3 2

[development doc updates]
by Fred L. Drake 13 Mar '02

13 Mar '02

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Mostly minor updates; closed a few bug reports.

1 0

Python interpreter crash.
by Gustavo Cordova 13 Mar '02

13 Mar '02

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) >>> mod 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 > gcordova(a)sismex.com Å 8351-3861 | 8351-3862

6 7

"funny".split("")
by Christian Tismer 12 Mar '02

12 Mar '02

Hi Folks, I'm just translating the Python Pocked Reference the second time, and I stumbled over this: "funny".split("") gives a ValueError: empty separator. Why this? I would expect ['f','u','n','n','y'] as result, since this is the maximum result of undoing "".join(['f','u','n','n','y']) For what reason is this asymmetry? -- Christian Tismer :^) <mailto:tismer@tismer.com> 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/

6 17

RE: [Python-Dev] I'm an idiot...
by Tim Peters 12 Mar '02

12 Mar '02

[Skip Montanaro] > I checked in a trivial, but incorrect, change to popen2.py just > now. How to I undo that? Instructions for reverting a checkin are in part 2.7 of the FAQ: http://python.sourceforge.net/sf-faq.html#c7

2 1