Mailman 3 April 2000 - Python-Dev

Re: [Idle-dev] Forward progress with full backward compatibility
by pf＠artcom-gmbh.de April 11, 2000

April 11, 2000

Hi! David Scherer on idle-dev(a)python.org: [...] > in the interpreter* is fast. In principle, one could put THREE operators in > the language: one with the new "float division" semantics, one that divided > only integers, and a "backward compatibility" operator with EXACTLY the old > semantics: [...] > An outline of what I did: [...] Yes, this really clever. I like the ideas. [me]: > > 2. What should the new Interpreter do, if he sees a source file without a > > pragma defining the language level? There are two possibilities: [...] > > 2. Assume, it is a new source file and apply language level 2 to it. > > This has the disadvantage, that it will break any existing code. > I think the answer is 2. A high-quality script for adding the pragma to > existing files, with CLI and GUI interfaces, should be packaged with Python. > Running it on your existing modules would be part of the installation > process. Okay. But what is with the Python packages available on the Internet? May be the upcoming dist-utils should handle this? Or should the Python core distribution contain a clever installer program, which handles this? > Long-lived modules should always have a language level, since it makes them > more robust against changes and also serves as documentation. A version > statement could be encouraged at the top of any nontrivial script, e.g: > > python 1.6 [...] global python_1_5 #implies global old_division or global python_1_6 #implies global old_division or global python_1_7 #may be implies global new_division may be we can solve another issue just discussed on python_dev with global source_iso8859_1 or global source_utf_8 Cute idea... but we should keep the list of such pragmas short. > Personally, I think that it makes more sense to talk about ways to > gracefully migrate individual changes into the language than to put off > every backward-incompatible change to a giant future "flag day" that will > break all existing scripts. Versioning of some sort should be encouraged > starting *now*, and incorporated into 1.6 before it goes final. Yes. > Indeed, but Guido has spoken: > > > Great ideas there, Bruce! I hope you will post these to an > > appropriate mailing list (perhaps idle-dev, as there's no official SIG > > to discuss the Python 3000 transition yet, and python-dev is closed). May be someone can invite you into 'python-dev'? However the archives are open to anyone and writing to the list is also open to anybody. Only subscription is closed. I don't know why. Regards, Peter P.S.: Redirected Reply-To: to David and python-dev(a)python.org ! -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)

2 1

Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.5,2.6
by Greg Stein April 10, 2000

April 10, 2000

Euh... this is the incorrect fix. The 0 is wrong to begin with. Mark Favas submitted a proper patch for this. See his "Revised Patches for bug report 258" posted to patches(a)python.org on April 4th. Cheers, -g On Mon, 10 Apr 2000, Guido van Rossum wrote: > Update of /projects/cvsroot/python/dist/src/Modules > In directory eric:/projects/python/develop/guido/src/Modules > > Modified Files: > mmapmodule.c > Log Message: > I've had complaints about the comparison "where >= 0" before -- on > IRIX, it doesn't even compile. Added a cast: "where >= (char *)0". > > > Index: mmapmodule.c > =================================================================== > RCS file: /projects/cvsroot/python/dist/src/Modules/mmapmodule.c,v > retrieving revision 2.5 > retrieving revision 2.6 > diff -C2 -r2.5 -r2.6 > *** mmapmodule.c 2000/04/05 14:15:31 2.5 > --- mmapmodule.c 2000/04/10 21:14:05 2.6 > *************** > *** 2,6 **** > / Author: Sam Rushing <rushing(a)nightmare.com> > / Hacked for Unix by A.M. Kuchling <amk1(a)bigfoot.com> > ! / $Id: mmapmodule.c,v 2.5 2000/04/05 14:15:31 fdrake Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > --- 2,6 ---- > / Author: Sam Rushing <rushing(a)nightmare.com> > / Hacked for Unix by A.M. Kuchling <amk1(a)bigfoot.com> > ! / $Id: mmapmodule.c,v 2.6 2000/04/10 21:14:05 guido Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > *************** > *** 119,123 **** > char * where = (self->data+self->pos); > CHECK_VALID(NULL); > ! if ((where >= 0) && (where < (self->data+self->size))) { > value = (char) *(where); > self->pos += 1; > --- 119,123 ---- > char * where = (self->data+self->pos); > CHECK_VALID(NULL); > ! if ((where >= (char *)0) && (where < (self->data+self->size))) { > value = (char) *(where); > self->pos += 1; > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/

2 1

Unicode input issues
by Guido van Rossum April 10, 2000

April 10, 2000

Thinking about entering Japanese into raw_input() in IDLE more, I thought I figured a way to give Takeuchi a Unicode string when he enters Japanese characters. I added an experimental patch to the readline method of the PyShell class: if the line just read, when converted to Unicode, has fewer characters but still compares equal (and no exceptions happen during this test) then return the Unicode version. This doesn't currently work because the built-in raw_input() function requires that the readline() call it makes internally returns an 8-bit string. Should I relax that requirement in general? (I could also just replace __builtin__.[raw_]input with more liberal versions supplied by IDLE.) I also discovered that the built-in unicode() function is not idempotent: unicode(unicode('a')) returns u'\000a'. I think it should special-case this and return u'a' ! Finally, I believe we need a way to discover the encoding used by stdin or stdout. I have to admit I know very little about the file wrappers that Marc wrote -- is it easy to get the encoding out of them? IDLE should probably emulate this, as it's encoding is clearly UTF-8 (at least when using Tcl 8.1 or newer). --Guido van Rossum (home page: http://www.python.org/~guido/)

2 8

Getting ready for 1.6 alpha 2
by Guido van Rossum April 10, 2000

April 10, 2000

I'm getting ready for the release of alpha 2. Tomorrow afternoon (around 5:30pm east coast time) I'm going on vacation for the rest of the week, followed by a business trip most of the week after. Obviously, I'm anxious to release a solid alpha tomorrow. Please, send only simple or essential patches between now and the release date! --Guido van Rossum (home page: http://www.python.org/~guido/)

2 7

"takeuchi": a unicode string on IDLE shell
by Guido van Rossum April 10, 2000

April 10, 2000

Can anyone answer this? I can reproduce the output side of this, and I believe he's right about the input side. Where should Python migrate with respect to Unicode input? I think that what Takeuchi is getting is actually better than in Pythonwin or command line (where he gets Shift-JIS)... --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Mon, 10 Apr 2000 22:49:45 +0900 From: "takeuchi" <takeuchi.shohei(a)lab.ntt.co.jp> To: <guido(a)python.org> Subject: a unicode string on IDLE shell Dear Guido, I plaied your latest CPython(Python1.6a1) on Win98 Japanese version, and found a strange IDLE shell behavior. I'm not sure this is a bug or feacher, so I report my story anyway. When typing a Japanese string on IDLE shell with IME , Tk8.3 seems to convert it to a UTF-8 representation. Unfortunatly Python does not know this, it is dealt with an ordinary string. >>> s = raw_input(">>>") Type Japanese characters with IME for example $B$"(B (This is the first character of Japanese alphabet, Hiragana) >>> s '\343\201\202' # UTF-8 encoded >>> print s $B$"(B # A proper griph is appear on the screen Print statement on IDLE shell works fine with a UTF-8 encoded string,however,slice operation or len() does not work. # I know this is a right result So I have to convert this string with unicode(). >>> u = unicode(s) >>> u u'\u3042' >>> print u $B$"(B # A proper griph is appear on the screen Do you think this convertion is unconfortable ? I think this behavior is inconsistant with command line Python and PythonWin. If I want the same result on command line Python shell or PythonWin shell, I have to code as follows; >>> s = raw_input(">>>") Type Japanese characters with IME for example $B$"(B >>>s '\202\240' # Shift-JIS encoded >>> print s $B$"(B # A proper griph is appear on the screen >>> u = unicode(s,"mbcs") # if I use unicode(s) then UnicodeError is raised ! >>>print u.encode("mbcs") # if I use print u then wrong griph is appear $B$"(B # A proper griph is appear on the screen This difference is confusing !! I do not have the best solution for this annoyance, I hope at least IDLE shell and PythonWin shell would have the same behavior . Thank you for reading. Best Regards, takeuchi ------- End of Forwarded Message

2 1

Re: [Python-checkins] CVS: python/dist/src/Lib urlparse.py,1.22,1.23
by Greg Stein April 10, 2000

April 10, 2000

On Mon, 10 Apr 2000, Guido van Rossum wrote: > Update of /projects/cvsroot/python/dist/src/Lib > In directory eric:/projects/python/develop/guido/src/Lib > > Modified Files: > urlparse.py > Log Message: > Some cleanup -- don't use splitfields/joinfields, standardize > indentation (tabs only), rationalize some code in urljoin... Why not use string methods? (the patch still imports from string) Cheers, -g -- Greg Stein, http://www.lyra.org/

2 1

Re: [Python-checkins] CVS: distutils/distutils cmd.py
by Greg Stein April 10, 2000

April 10, 2000

[ damn... can't see the code... went and checked it out... ] On Sun, 9 Apr 2000, Greg Ward wrote: > Update of /projects/cvsroot/distutils/distutils > In directory kaluha:/tmp/cvs-serv16575 > > Modified Files: > cmd.py > Log Message: > Added a check for the 'force' attribute in '__getattr__()' -- better than > crashing when self.force not defined. This seems a bit silly. Why don't you simply define .force in the __init__ method? Better yet: make the other guys crash -- the logic is bad if they are using something that isn't supposed to be defined on that particular Command object. Cheers, -g -- Greg Stein, http://www.lyra.org/

2 2

test_fork1 on Linux
by Fred L. Drake, Jr. April 10, 2000

April 10, 2000

I've just checked in changes to test_fork1.py make the test a little more sensible on Linux (where the assumption that the thread pids are the same as the controlling process doesn't hold). However, I'm still observing some serious weirdness with this test. As far as I've been able to tell, the os.fork() call always succeeds, but sometimes the parent process segfaults, and sometimes it locks up. It does seem to get to the os.waitpid() call, which isi appearantly where the failure actually occurs. (And sometimes everything works as expected!) If anyone here is particularly familiar with threading on Linux, I'd appreciate a little help, or even a pointer to someone who understands enough of the low-level aspects of threading on Linux that I can communicate with them to figure this out. Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

1 0

int division proposal in idle-dev
by Guido van Rossum April 10, 2000

April 10, 2000

David Scherer posted an interesting proposal to the idle-dev list for dealing with the incompatibility issues around int division. Bruce Sherwood also posted an interesting discussion there on how to deal with incompatibilities in general (culminating in a recommendation of David's solution). In brief, David abuses the "global" statement at the module level to implement a pragma. Not ideal, but kind of cute and backwards compatible -- this can be added to Python 1.5 or even 1.4 code without breaking! He proposes that you put "global olddivision" at the top of any file that relies on int/int yielding an int; a newer Python can then default to new division semantics. (He does this by generating a different opcode, which is also smart.) It's time to start thinking about a transition path -- Bruce's discussion and David's proposal are a fine starting point, I think. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Round Bug in Python 1.6?
by Christian Tismer April 10, 2000

April 10, 2000

Hi, asa side effect, I happened to observe the following rounding bug. It happens in Stackless Python, which is built against the pre-unicode CVS branch. Is this changed for 1.6, or might it be my bug? D:\python\spc>python Python 1.5.42+ (#0, Mar 29 2000, 20:23:26) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> round(3.1415926585, 4) 3.1415999999999999 >>> ^Z D:\python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> round(3.1415926585, 4) 3.1416 >>> ^Z ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : 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

9 13