Mailman 3 - Python-Dev

RE: [Patches] [Patch #101055] Cookie.py
by Tim Peters 19 Aug '00

19 Aug '00

Moving this over from patches to python-dev. My 2 cents: The primary job of a source control system is to maintain an accurate and easily retrieved historical record of a project. Tim O'Malley's ,v file records the history of his project, Python's should record the history of its. While a handful of people at CNRI have been able to (or could, if they were of a common mind to) keep track of a handful of exceptions in their heads, Python's CVS tree is available to the world now, and approximately nobody looking at it will have any knowledge of this discussion. If they ask CVS for a date-based snapshot of the past, they're using CVS for what it's *designed* for, and they should get back what they asked for. Have these kinds of tricks already been played in the CVS tree? I'm mildly concerned about that too, because whenever license or copyright issues are in question, an accurate historical record is crucial ("Now, Mr. Kuchling, isn't it true that you deliberately sabotaged the history of the Python project in order to obscure your co-conspirators' theft of my client's intellectual property?" <0.9 wink>). let's-honor-the-past-by-keeping-it-honest-ly y'rs - tim > -----Original Message----- > From: patches-admin(a)python.org [mailto:patches-admin@python.org]On > Behalf Of Fred L. Drake, Jr. > Sent: Friday, August 18, 2000 4:06 PM > To: noreply(a)sourceforge.net > Cc: akuchlin(a)mems-exchange.org; patches(a)python.org > Subject: Re: [Patches] [Patch #101055] Cookie.py > > > > noreply(a)sourceforge.net writes: > > I have a copy of Tim O'Malley's ,v file (in order to preserve the > > version history). I can either ask the SF admins to drop it into > > the right place in the CVS repository, but will that screw up the > > Python 1.6 tagging in some way? (I would expect not, but who > > knows?) > > That would have no effect on any of the Python tagging. It's > probably worthwhile making sure there are no tags in the ,v file, but > that can be done after it gets dropped in place. > Now, Greg Stein will tell us that dropping this into place is the > wrong thing to do. What it *will* screw up is people asking for the > state of Python at a specific date before the file was actually added; > they'll get this file even for when it wasn't in the Python CVS tree. > I can live with that, but we should make a policy decision for the > Python tree regarding this sort of thing. > > > The second option would be for me to retrace Cookie.py's > > development -- add revision 1.1, check in revision 1.2 with the > > right log message, check in revision 1.3, &c. Obviously I'd prefer > > to not do this. > > Don't -- it's not worth it. > > > -Fred > > -- > Fred L. Drake, Jr. <fdrake at beopen.com> > BeOpen PythonLabs Team Member > > > _______________________________________________ > Patches mailing list > Patches(a)python.org > http://www.python.org/mailman/listinfo/patches

1 0

Re: [Patches] [Patch #101055] Cookie.py
by Andrew Kuchling 19 Aug '00

19 Aug '00

[Overquoting for the sake of python-dev readers] On Fri, Aug 18, 2000 at 04:06:20PM -0400, Fred L. Drake, Jr. wrote: >amk writes: > > I have a copy of Tim O'Malley's Cookie.py,v file (in order to preserve the > > version history). I can either ask the SF admins to drop it into > > the right place in the CVS repository, but will that screw up the > > Python 1.6 tagging in some way? (I would expect not, but who > > knows?) > > That would have no effect on any of the Python tagging. It's >probably worthwhile making sure there are no tags in the ,v file, but >that can be done after it gets dropped in place. > Now, Greg Stein will tell us that dropping this into place is the >wrong thing to do. What it *will* screw up is people asking for the >state of Python at a specific date before the file was actually added; >they'll get this file even for when it wasn't in the Python CVS tree. >I can live with that, but we should make a policy decision for the >Python tree regarding this sort of thing. Excellent point. GvR's probably the only person whose ruling matters on this point; I'll try to remember it and bring it up whenever he gets back (next week, right?). > Don't -- it's not worth it. I hate throwing away information that stands even a tiny chance of being useful; good thing the price of disk storage keeps dropping, eh? The version history might contain details that will be useful in future debugging or code comprehension, so I dislike losing it forever. (My minimalist side is saying that the enhanced Web tools should be a separately downloadable package. But you probably guessed that already...) --amk

4 4

Python-dev summary: Jul 1-15
by Andrew Kuchling 18 Aug '00

18 Aug '00

Note: this is an experiment in whether I can make a useful, interesting, somewhat coherent summary of python-dev activity. Things I'm not sure of: * Accuracy. I skipped past some threads such as the list comprehensions one, and may be unaware of a resolution. * How many links are needed? Should I try to link to several posts per thread, SF patches, etc.? That makes more work for me, but also makes the summary more useful. * Bi-weekly OK? I think it's a reasonable frequency. I'll check my e-mail tomorrow; if no one screams loudly, I'll post it. (My connectivity is poor enough that I don't want to do major editing on it, or be able to respond to many e-mails in detail.) ================== Python-dev summary, July 1-15, 2000: The 2-week period started with reactions to Guido's June 30 announcement that the 2.0b1 release would be delayed for an indefinite period due to legal wrangling. This gave everyone a second chance to contribute more patches while waiting for the release, and the activity level remained high. Two dominant issues for this time period were Unicode-related issues, and list comprehensions. The Unicode issues, as usual, turned on the question of where strings and Unicode strings should be interchangeable. A discussion in the thread "Minidom and Unicode" considered whether it's legal to return a Unicode string from __repr__. The consensus was that it should be legal, despite fears of breaking code that expects only an 8-bit string, and the CVS tree was patched accordingly. Python's interpreter mode uses repr() to display the results of expressions, and it will convert Unicode strings to ASCII, using the unicode-escape encoding. The following code, typed into the interpreter, will print 'abc\u3456'. class C: def __repr__(self): return u'abc\u3456' print repr( C() ) Hashing also presented a problem. As M.-A. Lemburg explained in http://www.python.org/pipermail/python-dev/2000-July/012150.html: The problem comes from the fact that the default encoding can be changed to a locale specific value (site.py does the lookup for you), e.g. given you have defined LANG to be us_en, Python will default to Latin-1 as default encoding. This results in 'äöü' == u'äöü', but hash('äöü') != hash(u'äöü'), which is in conflict with the general rule about objects having the same hash value if they compare equal. The resolution seems to be simply removing the ability to change the default encoding and adopt ASCII as the fixed default; if you want to use other encodings, you must specify them explicitly. List comprehensions originated as a patch from Greg Ewing that's now being kept up-to-date versus the CVS tree by Skip Montanaro. Originally they weren't on the roadmap for 1.6, but with the greater version number jump to 2.0, GvR is more willing to incorporate larger changes. List comprehensions provide a more concise way to create lists in situations where map() and filter() would currently be used. To take some examples from the patched-for-list-comphrensions version of the Python Tutorial: >>> spcs = [" Apple", " Banana ", "Coco nut "] >>> print [s.strip() for s in spcs] ['Apple', 'Banana', 'Coco nut'] >>> vec1 = [2, 4, 6] >>> vec2 = [4, 3, -9] >>> print [x*y for x in vec1 for y in vec2] [8, 6, -18, 16, 12, -36, 24, 18, -54] A lengthy subthread about intuitiveness sprang from the second example, and from a patch from Thomas Wouters that implements parallel 'for' loops. The patch makes "for x in [1,2]; y in ['a','b']" cause x,y to be 1,'a', and then 2,'b'. The thread circulated around whether people would expect this syntax to produce the Cartesian product of the two lists: (1,'a'), (1, 'b'), (2, 'a'), (2, 'b'). No clear answer or final syntax has emerged yet, though Greg Wilson has been trying out syntaxes on Python-unaware people and asking them what they'd expect: http://www.python.org/pipermail/python-dev/2000-July/012810.html It was also suggested to add a new built-in function for parallel 'for' loops instead of new syntax, so you would code 'for x,y in zip([1,2], ['a','b']):'. A lengthy and very dull discussion ensued about the name 'zip': should it be 'plait', 'knit', 'parallel', or even 'marry'? Some new procedures for Python development were set out: Tim Peters wrote some guidelines for using SourceForge's patch manager: http://www.python.org/pipermail/python-dev/2000-July/012635.html Barry Warsaw announced a series of Python Extension Proposal (PEP) documents, which play the role of RFCs for significant changes to Python: http://www.python.org/pipermail/python-dev/2000-July/013059.html Mark Hammond gave the first glimpse of a fourth Python implementation: "This new compiler could be compared, conceptually, with JPython - it is a completely new implementation of Python. It has a compiler that generates native Windows .DLL/.EXE files. It uses a runtime that consists of a few thousand lines of C# (C-Sharp) code. The Python programs can be debugged at the source level with Visual Studio 7, as well as stand-alone debuggers for this environment. Python can sub-class VB or C# classes, and vice-versa." http://www.python.org/pipermail/python-dev/2000-July/013019.html Other bits: Skip Montanaro experimented with using code coverage tools to measure the effectiveness of the Python test suite, by seeing which lines of code (both C and Python) that are exercised by the tests. A summary of the results is at: http://www.musi-cal.com/~skip/python/Python/dist/src/summary.html Skip also added support to the readline module for saving and loading command histories. ESR suggested adding a standard lexer to the core, and /F suggested an extension to regular expressions that would make them more useful for tokenizing: http://www.python.org/pipermail/python-dev/2000-July/012032.html CVS problems were briefly a distraction, with dangling locks preventing commits to the Lib/ and Modules/ subdirectories for a few days. Despite such glitches, the move to SourceForge has accelerated development overall, as more people can make check-ins and review them. For some time Tim Peters has been suggesting removing the Py_PROTO macro and making the sources require ANSI C; mostly this is because the macro breaks the C cross-referencing support in Tim's editor. :) The ball finally started rolling on this, and snowballed into a massive set of patches to use ANSI C prototypes everywhere. Fred Drake and Peter Schneider-Kamp rose to the occasion and edited the prototypes in dozens of files. Jeremy Hylton pointed out that "Tuple, List, String, and Dict have a Py*_Size method. The abstract object interface uses PySequence_Length. This is inconsistent and hard to remember," and suggested that *_Size be made the standard form, and *_Length will be deprecated. Just before the cutoff date, Paul Prescod proposed a new help() function for interactive use, and began implementing it: http://www.python.org/pipermail/python-dev/2000-July/013346.html Huaiyu Zhu suggested adding new operators to support matrix math: http://www.python.org/pipermail/python-dev/2000-July/013364.html A slew of minor patches and bugfixes were made, too. Some highlights: * Ka-Ping Yee improved the syntax error messages. * ESR made various changes to ConfigParser.py * Some of Sam Rushing's patches from Medusa were applied to add os.setreuid() and friends; AMK is working on adding the poll() system call. * /F was his usual "patching machine" self, integrating PythonWin's win32popen function so that os.popen will now work correctly on Windows as well as Unix, writing PyErr_SafeFormat() to prevent buffer overflows, and proposing some patches to reduce the 600K size of the Unicode character database. Some fun posts came up during the near-endless zip()/plait()/whatever naming thread: http://www.python.org/pipermail/python-dev/2000-July/012920.html: "BTW: How comes, that Ping very often invents or introduces very clever ideas and concepts, but also very often chooses unclear names for them? Is it just me not being a native english speaker?" "I don't know. Perhaps my florx bignal zupkin isn't very moognacious?" -- Peter Funk and Ka-Ping Yee, 12 Jul 2000 http://www.python.org/pipermail/python-dev/2000-July/013050.html, while everyone was trying to think up alternative names for zip(): "Let me throw one more out, in honor of our fearless leader's recent life change: marry(). Usually only done in pairs, and with two big sequences, I get the image of a big Unification Church event :)" "Isn't it somewhat of a political statement to allow marriages of three or more items? I always presumed that this function was n-ary, like map." -- Barry Warsaw and Paul Prescod

9 9

Re: [Python-Dev] Preventing recursion core dumps
by Jack Jansen 18 Aug '00

18 Aug '00

Isn't the solution to this problem to just implement PyOS_CheckStack() for unix? I assume you can implement it fairly cheaply by having the first call compute a stack warning address and subsequent calls simply checking that the stack hasn't extended below the limit yet. It might also be needed to add a few more PyOS_CheckStack() calls here and there, but I think most of them are in place. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

[PEP 214] FW: sys.stndout syntax
by Tim Peters 18 Aug '00

18 Aug '00

For those of you who stopped reading comp.lang.python, note that this is *typical* of the advice users get in the absence of syntactic "print" sugar. it's-not-exactly-intuitive-that-a-"print"-stmt-isn't-meant-to- do-output<wink>-ly y'rs - tim -----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Jeff Kunce Sent: Friday, August 18, 2000 3:41 PM To: python-list(a)python.org Subject: Re: sys.stndout syntax > on win32, to get printed output to a file i use > >>> sys.stndout = open('file.txt', 'w') > how do i get it to go back to the command line #Here is the specific solution for those who remember the secret password: sys.stdout = open('file.txt', 'w') print 'this is written to file.txt' sys.stdout.close() sys.stdout = sys.__stdout__ print 'this is written to console' #Here is the general solution if you can't be bothered with remembering secret passwords: original_stdout = sys.stdout sys.stdout = open('file.txt', 'w') print 'this is written to file.txt' sys.stdout.close() sys.stdout = original_stdout print 'this is written to console' --Jeff -- http://www.python.org/mailman/listinfo/python-list

2 2

pthreads question: typedef ??? pthread_t and hacky return statements
by Trent Mick 18 Aug '00

18 Aug '00

I am porting Python to Monterey (64-bit AIX) and have a small (hopefully) question about POSIX threads. I have Monterey building and passing the threads test suite using Python/thread_pthread.h with just one issue: -------------- snipped from current thread_pthread.h --------------- long PyThread_get_thread_ident(void) { volatile pthread_t threadid; if (!initialized) PyThread_init_thread(); /* Jump through some hoops for Alpha OSF/1 */ threadid = pthread_self(); return (long) *(long *) &threadid; } ------------------------------------------------------------------- Does the POSIX threads spec specify a C type or minimum size for pthread_t? Or can someone point me to the appropriate resource to look this up. On Linux (mine at least): /usr/include/bits/pthreadtypes.h:120:typedef unsigned long int pthread_t; On Monterey: typedef unsigned int pthread_t; That is fine, they are both 32-bits, however Monterey is an LP64 platform (sizeof(long)==8, sizeof(int)=4), which brings up the question: WHAT IS UP WITH THAT return STATEMENT? return (long) *(long *) &threadid; My *guess* is that this is an attempt to just cast 'threadid' (a pthread_t) to a long and go through hoops to avoid compiler warnings. I dont' know what else it could be. Is that what the "Alpha OSF/1" comment is about? Anybody have an Alpha OSF/1 hanging around. The problem is that when sizeof(pthread_t) != sizeof(long) this line is just broken. Could this be changed to return threadid; safely? Thanks, Trent -- Trent Mick TrentM(a)ActiveState.com

11 30

Re: [Python-Dev] PEP 214, extended print statement
by Greg Wilson 18 Aug '00

18 Aug '00

> Barry Warsaw wrote: > [extended print PEP] +1 --- it'll come in handy when teaching newbies on Windows and Unix simultaneously. Greg

9 14

Re: [Python-checkins] CVS: python/dist/src/Objects object.c,2.95,2.96
by Trent Mick 18 Aug '00

18 Aug '00

On Thu, Aug 17, 2000 at 10:01:22PM -0700, Barry Warsaw wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory slayer.i.sourceforge.net:/tmp/cvs-serv28173 > > Modified Files: > object.c > Log Message: > make_pair(): When comparing the pointers, they must be cast to integer > types (i.e. Py_uintptr_t, our spelling of C9X's uintptr_t). ANSI > specifies that pointer compares other than == and != to non-related > structures are undefined. This quiets an Insure portability warning. > > > Index: object.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/object.c,v > retrieving revision 2.95 > retrieving revision 2.96 > diff -C2 -r2.95 -r2.96 > *** object.c 2000/08/16 12:24:51 2.95 > --- object.c 2000/08/18 05:01:19 2.96 > *************** > *** 372,375 **** > --- 372,377 ---- > { > PyObject *pair; > + Py_uintptr_t iv = (Py_uintptr_t)v; > + Py_uintptr_t iw = (Py_uintptr_t)w; > > pair = PyTuple_New(2); > *************** > *** 377,381 **** > return NULL; > } > ! if (v <= w) { > PyTuple_SET_ITEM(pair, 0, PyLong_FromVoidPtr((void *)v)); > PyTuple_SET_ITEM(pair, 1, PyLong_FromVoidPtr((void *)w)); > --- 379,383 ---- > return NULL; > } > ! if (iv <= iw) { > PyTuple_SET_ITEM(pair, 0, PyLong_FromVoidPtr((void *)v)); > PyTuple_SET_ITEM(pair, 1, PyLong_FromVoidPtr((void *)w)); > *************** > *** 488,492 **** > } > if (vtp->tp_compare == NULL) { > ! return (v < w) ? -1 : 1; > } > _PyCompareState_nesting++; > --- 490,496 ---- > } > if (vtp->tp_compare == NULL) { > ! Py_uintptr_t iv = (Py_uintptr_t)v; > ! Py_uintptr_t iw = (Py_uintptr_t)w; > ! return (iv < iw) ? -1 : 1; > } > _PyCompareState_nesting++; > Can't you just do the cast for the comparison instead of making new variables? Trent -- Trent Mick TrentM(a)ActiveState.com

3 3

[Bug #111620] lots of use of send() without verifying amount of data sent
by Charles G Waldman 18 Aug '00

18 Aug '00

I'm jumping in late to this discussion to mention to mention that even for sockets in blocking mode, you can do sends with the MSG_DONTWAIT flag: sock.send(msg, socket.MSG_DONTWAIT) and this will send only as much data as can be written immediately. I.E., a per-message non-blocking write, without putting the socket into blocking mode. So if somebody decides to raise an exception on short TCP writes, they need to be aware of this. Personally I think it's a bad idea to be raising an exception at all for short writes.

1 0

Cookie.py module, and Web PEP
by Andrew Kuchling 18 Aug '00

18 Aug '00

Tim O'Malley finally mailed me the correct URL for the latest version of the cookie module: http://www.timo-tasi.org/python/Cookie.py *However*... I think the Web support in Python needs more work in generally, and certainly more than can be done for 2.0. One of my plans for the not-too-distant future is to start writing a Python/CGI guide, and the process of writing it is likely to shake out more ugliness that should be fixed. I'd like to propose a 'Web Library Enhancement PEP', and offer to champion and write it. Its goal would be to identify missing features and specify them, and list other changes to improve Python as a Web/CGI language. Possibly the PEP would also drop backward-compatibility cruft. (Times like this I wish the Web-SIG hadn't been killed...) --amk

2 1