Mailman 3 July 2005 - Python-Dev

PEP 343 documentation on Sourceforge Patch tracker
by Nick Coghlan July 7, 2005

July 7, 2005

I've put the draft documentation on the SF tracker, as Patch ID #1234057 [1]. The version posted there has a few changes from the last draft I mailed to the list, including: - mention try/finally, then describe with statements as a way to eliminate the associated boilerplate - clean up some terminology issues in the opening section that were holdovers from the 'suite management' version - switch to contextmanager as the decorator name - a couple of name changes in the contextmanager sample code - a few minor editiorial fixes It still needs addition of latex formatting codes. I also kept the enter/exit terminology, since that is the only one Guido has given blessing to (by approving PEP 343 using those method names) Cheers, Nick. [1] http://www.python.org/sf/1234057 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

1 0

Re: [Python-Dev] 'With' context documentation draft (was Re:Terminology for PEP 343
by Delaney, Timothy (Tim) July 6, 2005

July 6, 2005

Raymond Hettinger wrote: > These names should be changed to __beginwith__ and __endwith__. The Alternatively: __begincontext__ / __endcontext__ __enterwith__ / __exitwith__ __entercontext__ / __exitcontext__ __begin_with__ / __end_with__ __begin_context__ / __end_context__ __enter_with__ / __exit_with__ __enter_context__ / __exit_context__ :) Tim Delaney

1 0

Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
by Delaney, Timothy (Tim) July 6, 2005

July 6, 2005

Well, I'm convinced. My votes go to "context management protocol" and @contextmanager. Simple, descriptive and specific in meaning yet wide enough to cover pretty much all the cases we care about. I think we should state in the docs that the most common usage is to set up a specific context and restore the context to what it was before the with statement at the end of the with statement. Any other use should contain dire warnings ;) This works for the HTML tags - the original context is being outside the <html> tag - and the additional explanation is sufficient warning IMO. Tim Delaney

1 0

Expanding max chunk size to 4GB.
by Mark Rages July 6, 2005

July 6, 2005

The RIFF chunk size (used by the Python wave library) is 2GB, because the length is read as a signed 32-bit integer. The attached patch to chunk.py raises the limit to 4GB by using a signed integer. Is this correct? Is there a more general solution to 32-bit addressing limitation in wave files? Multiple chunks? Set the length field to zero and let software assume we only have one chunk? Regards, Mark Rages markrages(a)gmail.com -- You think that it is a secret, but it never has been one. - fortune cookie

3 5

Request to add developer
by A.M. Kuchling July 6, 2005

July 6, 2005

I wish to request that 'gregorykjohnson' be added to the Python SF project. Gregory is the participant I'm mentoring in Google's Summer of Code program. His project is enhancing mailbox.py to give it the ability to modify mailboxes as well as read them; see http://gkj.freeshell.org/summer_of_code/ for his proposal and code sketches. This project seems to belong in nondist/sandbox/ ; I'll impress upon him that he shouldn't commit any changes to mailbox.py in the distribution tree until everything is done. (Trivia: He'll be the fourth 'Greg' or 'Gregory' with Python commit privs, breaking the tie between Gregs and Andrews; currently there are three of each.) --amk

2 1

Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
by Michael Chermside July 6, 2005

July 6, 2005

Nick writes sample documentation: > For example, the following context manager allows prompt closure of > any resource with a 'close' method (e.g. a generator or file): > > @context > def closing(resource): > try: > yield resource > finally: > resource.close() Reading this I get the feeling that perhaps the decorator should be named "context_manager" not "context": @context_manager def closing(resource): try: yield resource finally: resource.close() Does anyone else agree? Paul Moore writes: > I also like the fact that it offers a neat 1-word name for the > generator decorator, "@context". Well, ok... does anyone *else* agree? I too saw this and thought "neat! a simple one-word name!". But then I started worrying that it's not defining the *context*, but rather the *context manager*. While "context manager" is a term I could easily imagine associating only with 'with' statements, "context" is too general a term... even after Python supports 'with' statements I will continue to use "context" to mean lots of different things (eg: decimal.context). By the way, great job Nick... these docs read quite nicely. -- Michael Chermside

3 2

Possible C API problem?
by Gary Robinson July 6, 2005

July 6, 2005

Hello, I was asking about a problem I was having over on the C++-python list, and they suggested I report it here as a possible Python problem. I was getting bus errors with a C module I was linking to, so factored it down too a very small example that reproduced the problem. Here it is: #include <Python.h> static double gfSumChiSquare = 123.0; static PyObject * getSumChiSquare(PyObject *self, PyObject *args){ return Py_BuildValue("d", gfSumChiSquare); } static PyMethodDef SimMethods[] = { {"getSumChiSquare", getSumChiSquare, METH_NOARGS, "Return fSumChiSquare"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC inittestfloat(void) { (void) Py_InitModule("testfloat", SimMethods); } That caused a bus error 100% of the time when I simply imported the module into Python and called getSumChiSquare(), i.e.: >>> import testfloat >>> testfloat.getSumChiSquare() However, the problem seems to go away if I use METH_VARARGS, and parse the non-existent args with PyArg_ParseTuple: #include <Python.h> static double gfSumChiSquare = 123.0; static PyObject * getSumChiSquare(PyObject *self, PyObject *args){ if (!PyArg_ParseTuple(args, "", NULL)) return NULL; return Py_BuildValue("d", gfSumChiSquare); } static PyMethodDef SimMethods[] = { {"getSumChiSquare", getSumChiSquare, METH_VARARGS, "Return fSumChiSquare"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC inittestfloat(void) { (void) Py_InitModule("testfloat", SimMethods); } This approach seems to work reliably -- at least variations I've tried haven't caused a bus error. But I haven't been able to discern an explanation from the docs as to why this would be better. The docs say that both METH_VARARGS and METH_NOARGS expect a PyCFunction. So if I am calling the function with no arguments, why can't I use METH_NOARGS and skip the call to PyArg_ParseTuple? Could it be that this is a python bug? Or am I doing something wrong? Note: this is using Python 2.3 on OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) Thanks in advance for any help or insight you can give, Gary -- Gary Robinson CTO Emergent Music, LLC grobinson(a)goombah.com 207-942-3463 Company: http://www.goombah.com Blog: http://www.garyrobinson.net

4 7

using pyhon from the MSYS shell
by lode leroy July 6, 2005

July 6, 2005

I was trying to compile a python plugin (for gimp) using the MSYS shell and the MINGW compiler. I now have put this in 'sitecustomize' $ cat /c/Python24/lib/site-packages/sitecustomize.py import sys import os import re if os.environ.get("MSYSTEM") == "MINGW32": os.sep='/' os.pathsep='/' sys.prefix = re.sub('\\\\','/',sys.prefix) sys.exec_prefix = re.sub('\\\\','/',sys.exec_prefix) It would probably be better to have python detect that it's running from inside the msys shell, and output '/'es instead of '\'es. maybe someone could extend os.path to do this in the standard distribution: implement an msyspath.py, which calls ntpath for each function, and does a replace at the end of the evaluation. Unfortunately, I'm just starting to look into python, so I do not know what the cleanest implementation of this would be...

4 7

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser July 6, 2005

July 6, 2005

Patch / Bug Summary ___________________ Patches : 348 open ( +4) / 2879 closed ( +4) / 3227 total ( +8) Bugs : 898 open ( +1) / 5103 closed ( +9) / 6001 total (+10) RFE : 193 open ( +2) / 170 closed ( +0) / 363 total ( +2) New / Reopened Patches ______________________ tarfile.py: ExFileObject's tell() is wrong after readline() (2005-06-30) http://python.org/sf/1230446 opened by Lars Gustäbel Patch for (Doc) #1168746 (2005-06-30) CLOSED http://python.org/sf/1230615 opened by Peter van Kampen Patch for (Doc) #1162912 (2005-07-03) CLOSED http://python.org/sf/1231890 opened by Peter van Kampen audioop - alaw encoding/decoding added, code updated (2005-07-01) http://python.org/sf/1231053 opened by Lars Immisch Add unicode for sys.argv, os.environ, os.system (2005-07-02) http://python.org/sf/1231336 opened by Neil Hodgson Typo fix in compiler/transformer.py (WalkerEror) (2005-07-02) CLOSED http://python.org/sf/1231538 opened by Adrien Di Mascio MS Windows - module search path fix (2005-07-04) http://python.org/sf/1232023 opened by K. Thananchayan PyOS_Readline (2005-07-04) http://python.org/sf/1232343 opened by Lisandro Dalcin Patches Closed ______________ Patch for (Doc) #1168746 (2005-06-30) http://python.org/sf/1230615 closed by birkenfeld Patch for (Doc) #1162912 (2005-07-03) http://python.org/sf/1231890 closed by birkenfeld Patch for (Doc) bug #1228904 (2005-06-29) http://python.org/sf/1229935 closed by birkenfeld Typo fix in compiler/transformer.py (WalkerEror) (2005-07-02) http://python.org/sf/1231538 closed by birkenfeld New / Reopened Bugs ___________________ Build failure (2005-06-30) http://python.org/sf/1230161 opened by L.M tokenize bug (2005-06-30) http://python.org/sf/1230484 opened by Eduardo Aguiar sys.excepthook doesn't work in threads (2005-06-30) http://python.org/sf/1230540 opened by Jonathan Ellis decimal module is no longer 2.3 compatible (2005-06-30) CLOSED http://python.org/sf/1230553 opened by Mike Orr ioctl has problem with -ive request codes (2005-07-01) http://python.org/sf/1231069 opened by Barry Alan Scott chr() returns ? when input > 127 in OS X (2005-07-02) http://python.org/sf/1231488 opened by Craig Howard typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) CLOSED http://python.org/sf/1162912 reopened by birkenfeld OverflowError in time.utime() causes strange traceback (2005-07-04) CLOSED http://python.org/sf/1232517 opened by Joe Peterson Mistakes in online docs under "5.3 Pure Embedding" (2005-07-05) http://python.org/sf/1232768 opened by Matt Smart non-admin install may fail (win xp pro) (2005-07-05) http://python.org/sf/1232947 opened by pvrijlandt openssl-0.9.8 requires _ssl.mak change (2005-07-05) http://python.org/sf/1233049 opened by Alan Meyer Bugs Closed ___________ Two requests to one file are not done in parallel (2005-06-25) http://python.org/sf/1227480 closed by jafo usage of type "char*" instead of "const char*" (2005-06-27) http://python.org/sf/1228053 closed by tjreedy decimal module is no longer 2.3 compatible (2005-06-30) http://python.org/sf/1230553 closed by rhettinger frame.f_exc_type,value,traceback (2005-03-23) http://python.org/sf/1168746 closed by birkenfeld __getattribute__ documentation error? (2005-05-19) http://python.org/sf/1204734 closed by birkenfeld weakref example broken (2005-06-28) http://python.org/sf/1228904 closed by birkenfeld typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 closed by birkenfeld typesseq-mutable lacks note on combined key/cmp usage (2005-03-14) http://python.org/sf/1162912 closed by birkenfeld random.py/os.urandom robustness (2005-04-06) http://python.org/sf/1177468 closed by birkenfeld OverflowError in time.utime() causes strange traceback (2005-07-05) http://python.org/sf/1232517 closed by mwh New / Reopened RFE __________________ platform.processor() could be smarter (2005-07-01) http://python.org/sf/1231081 opened by Stephan Springer Links to tutorials and howtos from references (2005-07-04) http://python.org/sf/1232073 opened by Michael Hoffman

1 0

List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)
by Arthur July 6, 2005

July 6, 2005

>* and because Guido believes beginners tend to copy too much > (that is one reason why copy.copy is not a builtin) and that > the language should encourage correct behavior. OTOH, beginners tend to copy not enough - when for example iterating over a list being acting upon. Though my real argument for list.copy() as an aid to beginners is otherwise - a bit more obtuse/non-linear than that - so much so that it doesn't get much sympahty. It isn't realistic to expect beginners to pick up idioms near the outset of the learning process. Now, copying lists is not something the beginner will often want to do, and the argument that once they want to do so, they will also be comfortable with slicing and with more idiomatic Python is not an unreasonable argument. But I believe it misses something more fundamental. It is a belief that is extracted from my own experience in tackling Python as a first language - as an adult, being able - I think - to introspect a bit better as to the process than I could if I were doing so at a younger age, and more in the normal course. The downside of Guido hiding "copy" to the extent it is - by not having a list.copy(), by not having copy.copy as a built-in, by even rejecting the notion of a short blurb of the copy module in the tutorial - is that the confrontation with the distinction between copying and "=" assignment gets delayed and confusion on the point becomes frustrating - fundamentally so. It doens't seem to me that this is an outlandish notion by any means. It can't be - as I seemed to have experienced it. Guido called this "one of my favorite subjects" in my last go around here on this issue. Well, it is indeed an opinion I hold. Not of earthshaking importance. But I hold it firmly enough, nonetheless. My flexiblity is more on the issue as to the extent that Python should design itself around the needs of beginners. If the conclusion is that list.copy() is a distraction to the experienced programmer, and that the motivated beginner will get to where they need to get, in any case, with or without it - I'm on board. If the thought is that hiding "copy", or relying on idioms for a construct as fundamental as the list - is a favor to the beginner, I very much am not. Art

2 1