Mailman 3 June 2000 - Python-Dev

ascii.py
by Eric S. Raymond 05 Jun '00

05 Jun '00

Latest version. Adds isctrl() and ismeta() functions (because I use them...) Um. What's the checkin procedure for library modules? And do I have permissions to do it? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788

4 4

Re: Is it just Syntactic Sugar ?
by Thomas Wouters 05 Jun '00

05 Jun '00

On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote: > I know I shouldn't be posting in this thread, and I won't be there to read > the responses, but here's what I thought would be cool. As the 'lucky, lucky bastard' is probably standing before the altar about now, I'll send this to the dev-list instead. Not that I expect anyone *not* to be at the wedding, but I bet the rest is back sooner ;-) > x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" > (an old Algol-68 naming convention; we could pick something better later > but this will do for the explanation). > For immutable types, this is defined as > def __add_ab__(self, other): > return self+other > For mutable types, this is defined as a self-mutating operation, > e.g. for lists it could be > def __add_ab__(self, other): > self.extend(other) > return self This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ? I had a chat with Michael about fixing up his patch to work all the way (it's currently a proof-of-concept-quick-hack that only works for builtin types) which prompted me to study Python's internals a bit closer. (I hope I dont sound too patronizing when I say I was impressed ;-) I'm curious what should happen with index-assignment and slice-assignment: x[y] += z x[:y] += z (Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.) Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new object, a slice of x, and call its __add_ab__() method ? Or would it try all of them, or more, until it gets a good result ? Or am I running ahead of things and should we wait for a working patch first ? :) If I suddenly grow a deep understanding of Python's internals (not ruled out, it's fairly obvious) and hack-up something that works before anyone else, I'll be sure to mail ;) oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

4 3

Re: Revised 1.6 jobs list
by Neil Schemenauer 05 Jun '00

05 Jun '00

[David Ascher] >> test_fork1 fails on Linux with threads on SMP machines. (It's >> irrelevant without threads.) This is a hard failure -- the >> process can either SEGV or hang forever. Is this a showstopper? >> SMP boxes are becoming increasingly common both as servers and >> workstations. > > Why does the test fail? I'd hate to see the thousands (nay, > hundreds of thousands) of users complain that foo isn't working > just because the test for a rarely used feature on a rare > platform is broken. Threads and fork() don't seem to mix on Linux. Even on a UP machine things seem strange: http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=613477888&fmt=text I tried to reproduce the problem with a C program but could not. When things hang the forking thread is stuck in wait4() while the child process is suspended: #0 0x4027d9ba in sigsuspend () from /lib/libc.so.6 #1 0x40232c77 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x4023406e in __pthread_lock () from /lib/libpthread.so.0 #3 0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at thread_pthread.h:339 #5 0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64, locals=0x0, args=0x81be278, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:630 #6 0x805ac19 in call_function (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2552 #7 0x805a5a4 in PyEval_CallObjectWithKeywords (func=0x81ebb2c, arg=0x81be26c, kw=0x0) at ceval.c:2390 #8 0x80b2c7b in t_bootstrap (boot_raw=0x81ebb50) at ./threadmodule.c:224 #9 0x40230c8f in pthread_start_thread () from /lib/libpthread.so.0 I don't know if this is a LinuxThread problem or a Python problem. Neil -- The internet: Learn what you know. Share what you don't.

3 2

What's New (first draft)
by Andrew Kuchling 05 Jun '00

05 Jun '00

I've put up the crude first draft of a "What's New in Python 1.6" article, co-written with Moshe Zadka. Please offer comments (or even patches to the LaTeX!). http://www.python.net/crew/amk/python/writing/new-python/ PDF, DVI, ASCII, and the LaTeX source are in: ftp://www.python.net/pub/crew/amk/new/ Various people are mentioned by name in the document ("effbot did this; MAL did that; Christian did that other thing...") because I want to emphasize the number of contributors to this release; does everyone think this is a good idea? If I've missed your name, or credited you wrongly, please let me know. --amk

3 2

Suggestion: stopping to trust os mtimes
by Moshe Zadka 05 Jun '00

05 Jun '00

Trusting OS-based mtimes for .pyc caching has some inherent problems. (Clock syncing and similar) Frankly, though I've never been bitten by this, it does give me an uncomfortable feeling. What if, instead, we'd use md5- or sha-based approach? I'm willing to bet that the 2^128 chance of problems is miniscule compared to the real problems clock syncing has already caused. (I think I remember some problem with .pyc's on IIS, but I may just be hallucinating) Problems: .pyc size would increase by 24 bytes <wink> -- Moshe Zadka <moshez(a)math.huji.ac.il> http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com

6 13

autoconf macros (was: RE: [Patches] Patch to Modules/pcre.h)
by Greg Stein 03 Jun '00

03 Jun '00

[moving to python-dev] On Sun, 4 Jun 2000, Mark Hammond wrote: > > I don't even see where DONT_HAVE_SYS_TYPES_H is ever defined: > ... > > Is it defined in some Mac-specific project file? > > A few existed before, but I know I submitted a couple of the listed ones > for Windows CE. However, the CE config.h has never made it into the core, > hence you can't find that particular definition... Well, as I pointed out, the best way to do this is to add sys/types.h, sys/stat.h, and stat.h to the AC_CHECK_HEADER() macro in configure.in. The HAVE_SYS_TYPES_H macro and friends could then be checked. PC/wince_config.h (or whatever it is called) would just #undef the HAVE_* macros. The underlying issue here, is that autoconf can take care of these things for us quite easily -- that we don't need manual maintenance of the macros. For the odd platform without sys/types.h, autoconf will handle it, rather than Python needing to do a special-case declaration. Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0

Re: [Python-checkins] CVS: python/dist/src/Modules mmapmodule.c,2.8,2.9
by Greg Stein 03 Jun '00

03 Jun '00

Actually, PyArg_ParseTuple() is a better call for this. It allows you to specify the method name: if (!PyArg_ParseTuple(args, ":close")) return NULL; Cheers,, -g On Sat, 3 Jun 2000, A.M. Kuchling wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv21410 > > Modified Files: > mmapmodule.c > Log Message: > Add missing PyArg_NoArgs() calls to methods that didn't take arguments > (Pointed out by Moshe Zadka) > > > Index: mmapmodule.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/mmapmodule.c,v > retrieving revision 2.8 > retrieving revision 2.9 > diff -C2 -r2.8 -r2.9 > *** mmapmodule.c 2000/05/03 23:44:32 2.8 > --- mmapmodule.c 2000/06/03 19:41:42 2.9 > *************** > *** 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.8 2000/05/03 23:44:32 guido 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.9 2000/06/03 19:41:42 akuchling Exp $ > > / mmapmodule.cpp -- map a view of a file into memory > *************** > *** 76,79 **** > --- 76,81 ---- > mmap_close_method (mmap_object * self, PyObject * args) > { > + if (!PyArg_NoArgs(args)) > + return NULL; > #ifdef MS_WIN32 > UnmapViewOfFile (self->data); > *************** > *** 119,122 **** > --- 121,126 ---- > char * where; > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > if (self->pos >= 0 && self->pos < self->size) { > where = self->data + self->pos; > *************** > *** 132,136 **** > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > --- 136,140 ---- > static PyObject * > mmap_read_line_method (mmap_object * self, > ! PyObject * args) > { > char * start = self->data+self->pos; > *************** > *** 140,143 **** > --- 144,149 ---- > > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > eol = memchr(start, '\n', self->size - self->pos); > *************** > *** 154,158 **** > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > --- 160,164 ---- > static PyObject * > mmap_read_method (mmap_object * self, > ! PyObject * args) > { > long num_bytes; > *************** > *** 226,230 **** > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > --- 232,236 ---- > static PyObject * > mmap_write_byte_method (mmap_object * self, > ! PyObject * args) > { > char value; > *************** > *** 242,248 **** > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > > #ifdef MS_WIN32 > --- 248,256 ---- > static PyObject * > mmap_size_method (mmap_object * self, > ! PyObject * args) > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > > #ifdef MS_WIN32 > *************** > *** 347,350 **** > --- 355,360 ---- > { > CHECK_VALID(NULL); > + if (!PyArg_NoArgs(args)) > + return NULL; > return (Py_BuildValue ("l", self->pos) ); > } > *************** > *** 463,470 **** > > static int > ! mmap_buffer_getreadbuf(self, index, ptr) > ! mmap_object *self; > ! int index; > ! const void **ptr; > { > CHECK_VALID(-1); > --- 473,477 ---- > > static int > ! mmap_buffer_getreadbuf(mmap_object *self, int index, const void **ptr) > { > CHECK_VALID(-1); > *************** > *** 868,869 **** > --- 875,877 ---- > > } > + > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://www.python.org/mailman/listinfo/python-checkins > -- Greg Stein, http://www.lyra.org/

1 0

Protecting __name__ &c.
by Ka-Ping Yee 03 Jun '00

03 Jun '00

Would it be too much trouble to prevent replacing double-underscore attributes like __name__ and __file__? I'll accept a "consenting adults" argument -- it's just that somehow this makes me uneasy: Python 1.5.2 (#54, Jul 14 1999, 12:50:51) [C] on irix6 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import foo >>> foo.__name__ 'bar' >>> foo.__file__ 'bar.py' >>> foo <module 'bar' from 'bar.py'> Of course, there is no 'bar.py'. 'foo.py' just contains __file__ = 'bar.py' __name__ = 'bar' (If you say i deserved to be punished for such heresy, fine...) -- ?!ng

3 2

ascii.py?
by Eric S. Raymond 02 Jun '00

02 Jun '00

There has been a vast and echoing silence about the ascii.py module I posted here at Fred Drake's request. Is it really such a bad idea? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy

8 10

What's that sound?
by Paul Prescod 01 Jun '00

01 Jun '00

ActiveState announces four new Python-related projects (PythonDirect, Komodo, Visual Python, ActivePython). PythonLabs announces four planet-sized-brains are going to be working on the Python implementation full time. PythonWare announces PythonWorks. Is that the sound of pieces falling into place or of a rumbling avalanche "warming up" before obliterating everything in its path? -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International

6 8