Mailman 3 January 2005 - Python-Dev

Unix line endings required for PyRun* breaking embedded Python
by Stuart Bishop Jan. 22, 2005

Jan. 22, 2005

There is a discussion going on at the moment in postgresql-general about plpythonu (which allows you write stored procedures in Python) and line endings. The discussion starts here: http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php The problem appears to be that things are working as documented in PEP-278: There is no support for universal newlines in strings passed to eval() or exec. It is envisioned that such strings always have the standard \n line feed, if the strings come from a file that file can be read with universal newlines. So what happens is that if a Windows or Mac user tries to create a Python stored procedure, it will go through to the server with Windows line endings and the embedded Python interpreter will raise a syntax error for everything except single line functions. I don't think it is possible for plpythonu to fix this by simply translating the line endings, as this would require significant knowledge of Python syntax to do correctly (triple quoted strings and character escaping I think). The timing of this thread is very unfortunate, as PostgreSQL 8.0 is being released this weekend and the (hopefully) last release of the 2.3 series next week :-( -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/

7 12

PEP 246 - concrete assistance to developers of new adapter classes
by Nick Coghlan Jan. 21, 2005

Jan. 21, 2005

Phillip's monkey-typing PEP (and his goal of making it easy to write well behaved adapters) got me wondering about the benefits of providing an adaptation. Adapter class that could be used to reduce the boiler plate required when developing new adapters. Inheriting from it wouldn't be *required* in any way - doing so would simply make it easier to write a good adapter by eliminating or simplifying some of the required code. Being written in Python, it could also serve as good documentation of recommended adapter behaviour. For instance, it could by default preserve a reference to the original object and use that for any further adaptation requests: class Adapter(object): def __init__(self, original): self.original = original def __conform__(self, protocol): return adapt(self.original, protocol) Does anyone else (particularly those with PEAK and Zope interface experience) think such a class would be beneficial in encouraging good practices? Regards, Nick. -- Nick Coghlan | ncoghlan(a)email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net

2 1

Updated Monkey Typing pre-PEP
by Phillip J. Eby Jan. 21, 2005

Jan. 21, 2005

I've revised the draft today to simplify the terminology, discussing only two broad classes of adapters. Since Clark's pending proposals for PEP 246 align well with the concept of "extenders" vs. "independent adapters", I've refocused my PEP to focus exclusively on adding support for "extenders", since PEP 246 already provides everything needed for independent adapters. The new draft is here: http://peak.telecommunity.com/DevCenter/MonkeyTyping And you can view diffs from the previous version(s) here: http://peak.telecommunity.com/DevCenter/MonkeyTyping?action=info

5 6

Patch review [ 1093585 ] sanity check for readline remove/replace
by Michiel Jan Laurens de Hoon Jan. 21, 2005

Jan. 21, 2005

Patch review [ 1093585 ] sanity check for readline remove/replace The functions remove_history_item and replace_history_item in the readline module respectively remove and replace an item in the history of commands. As outlined in bug [ 1086603 ], both functions cause a segmentation fault if the item index is negative. This is actually a bug in the corresponding functions in readline, which return a NULL pointer if the item index is larger than the size of the history, but does not check for the item index being negative. I sent a patch to bug-readline(a)gnu.org, so this will probably be fixed in future versions of readline. But for now, we need a workaround in Python. The patched code checks if the item index is negative, and issues an error message if so. I have run the test suite after applying this patch, and I found no problems with it. Note that there is one more way to fix this bug, which is to interpret negative indeces as counting from the end (same as lists and strings for exampe). So remove_history_item(-1) removes the last item added to the history etc. In that case, get_history_item should change as well. Right now get_history_item(-1) returns None, so the patch introduces a small (and probably insignificant) inconsistency: get_history_item(-1) returns None but remove_history_item(-1) raises an error. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

1 0

PyCon Preliminary Program Announced!
by Steve Holden Jan. 21, 2005

Jan. 21, 2005

Dear Python Colleague: You will be happy to know that the PyCon Program Committee, after lengthy deliberations, has now finalized the program for PyCon DC 2005. I can tell you that the decision-making was very difficult, as the standard of submissions was even higher than last year. You can see the preliminary program at http://www.python.org/pycon/2005/schedule.html and it's obvious that this year's PyCon is going to be even fuller than the last. On innovation is that there will be activities of a more social nature on the Wednesday (and perhaps the Thursday) evening, as well as keynote speeches from Guido and two other luminaries. Remember that the early bird registration rates end in just over a week, so hurry on down to http://www.python.org/pycon/2005/register.html to be sure of your place in what will surely be the premier Python event of the year. As always, I would appreciate your help in getting the word out. Please forward this message to your favorite mailing lists and newsgroups to make sure that everyone has a chance to join in the fun! regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications

1 0

ANN: Free Trac/Subversion hosting at Python-Hosting.com (fwd)
by Skip Montanaro Jan. 20, 2005

Jan. 20, 2005

Thought I'd pass this along for people who don't read comp.lang.python. Skip

1 0

Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
by Michiel Jan Laurens de Hoon Jan. 20, 2005

Jan. 20, 2005

Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format The PyArg_ParseTuple function (PyObject *args, char *format, ...) parses the arguments args and stores them in the variables specified following the format argument. If format=="i", indicating an integer, but the corresponding Python object in args is not a Python int or long, a TypeError is thrown: TypeError: an integer is required For the "L" format, indicating a long long, instead a SystemError is thrown: SystemError: Objects/longobject.c:788: bad argument to internal function The submitted patch fixes this, however I think it is not the best way to do it. The original code (part of the convertsimple function in Python/getargs.c) is case 'L': {/* PY_LONG_LONG */ PY_LONG_LONG *p = va_arg( *p_va, PY_LONG_LONG * ); PY_LONG_LONG ival = PyLong_AsLongLong( arg ); if( ival == (PY_LONG_LONG)-1 && PyErr_Occurred() ) { return converterr("long<L>", arg, msgbuf, bufsize); } else { *p = ival; } break; } In the patch, a PyLong_Check and a PyInt_Check are added: case 'L': {/* PY_LONG_LONG */ PY_LONG_LONG *p = va_arg(*p_va, PY_LONG_LONG *); PY_LONG_LONG ival; /* ********** patch starts here ********** */ if (!PyLong_Check(arg) && !PyInt_Check(arg)) return converterr("long<L>", arg, msgbuf, bufsize); /* ********** patch ends here ********** */ ival = PyLong_AsLongLong(arg); if (ival == (PY_LONG_LONG)-1 && PyErr_Occurred()) { return converterr("long<L>", arg, msgbuf, bufsize); } else { *p = ival; } break; } However, the PyLong_AsLongLong function (in Objects/longobject.c) also contains a call to PyLong_Check and PyInt_Check, so there should be no need for another such check here: PY_LONG_LONG PyLong_AsLongLong(PyObject *vv) { PY_LONG_LONG bytes; int one = 1; int res; if (vv == NULL) { PyErr_BadInternalCall(); return -1; } if (!PyLong_Check(vv)) { if (PyInt_Check(vv)) return (PY_LONG_LONG)PyInt_AsLong(vv); PyErr_BadInternalCall(); return -1; } A better solution would be to replace the PyErr_BadInternalCall() in the PyLong_AsLongLong function by PyErr_SetString(PyExc_TypeError, "an integer is required"); This would make it consistent with PyInt_AsLong in Objects/intobject.c: long PyInt_AsLong(register PyObject *op) { PyNumberMethods *nb; PyIntObject *io; long val; if (op && PyInt_Check(op)) return PyInt_AS_LONG((PyIntObject*) op); if (op == NULL || (nb = op->ob_type->tp_as_number) == NULL || nb->nb_int == NULL) { PyErr_SetString(PyExc_TypeError, "an integer is required"); return -1; } By the way, I noticed that a Python float is converted to an int (with a deprecation warning), while trying to convert a Python float into a long long int results in a TypeError. Also, I'm not sure about the function of the calls to converterr (in various places in the convertsimple function); none of the argument type errors seem to lead to the warning messages created by converterr. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

1 0

Re: Zen of Python
by Timothy Fitz Jan. 20, 2005

Jan. 20, 2005

On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne <stephen.thorne(a)gmail.com> wrote: > "Flat is better than nested" has one foot in concise powerful > programming, the other foot in optimisation. > > foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable lookup. I find it amazingly hard to believe that this is implying optimization over functionality or clarity. There has to be another reason, yet I can't think of any.

5 4

python-dev Summary for 2004-12-01 through 2004-12-15 [draft]
by Brett C. Jan. 20, 2005

Jan. 20, 2005

Uh, life has been busy. Will probably send this one out this weekend some time so please get corrections in before then. ------------------------------------ ===================== Summary Announcements ===================== PyCon_ 2005 is well underway. The schedule is in the process of being finalized (just figuring out the order of the talks). And there is still time for the early-bird registration price of $175 ($125 students) before it expires on January 28th. Some day I will be all caught up with the Summaries... .. _PyCon: http://www.pycon.org ========= Summaries ========= ---------------------------------- PEPS: those existing and gestating ---------------------------------- [for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' topic] A proto-PEP covering the __source__ proposal from the `last summary`_ has been posted to python-dev. `PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute modules contained within packages. .. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins .. _PEP 338: http://www.python.org/peps/pep-0338.html Contributing threads: - `PEP: __source__ proposal <>`__ - `PEP 338: Executing modules inside packages with '-m' <>`__ ------------------- Deprecating modules ------------------- The xmllib module was deprecated but not listed in `PEP 4`_. What does one do? Well, this led to a long discussion on how to handle module deprecation. With the 'warning' module now in existence, PEP 4 seemed to be less important. It was generally agreed that listing modules in PEP 4 was no longer needed. It was also agreed that deleting deprecated modules was not needed; it breaks code and disk space is cheap. It seems that no longer listing documentation and adding a deprecation warning is what is needed to properly deprecate a module. By no longer listing documentation new programmers will not use the code since they won't know about it. And adding the warning will let old users know that they should be using something else. .. _PEP 4: http://www.python.org/peps/pep-0004.html Contributing threads: - `Deprecated xmllib module <>`__ - `Rewriting PEP4 <>`__ ------------------------------------------ PR to fight the idea that Python is "slow" ------------------------------------------ An article_ in ACM TechNews that covered 2.4 had several mentions that Python was "slow" while justifying the slowness (whether it be flexibility or being fast enough). Guido (rightfully) didn't love all of the "slow" mentions which I am sure we have all heard at some point or another. The suggestions started to pour in on how to combat this. The initial one was to have a native compiler. The thinking was that if we compiled to a native executable that people psychologically would stop the association of Python being interpreted which is supposed to be slow. Some people didn't love this idea since a native compiler is not an easy thing. Others suggested including Pyrex with CPython, but didn't catch on (maintenance issue plus one might say Pyrex is not the most Pythonic solution). This didn't get anywhere in the end beyond the idea of a SIG about the various bundling tools (py2app, py2exe, etc.). The other idea was to just stop worrying about speed and move on stomping out bugs and making Python functionally more useful. With modules in the stdlib being rewritten in C for performance reasons it was suggested we are putting out the perception that performance is important to us. Several other people also suggested that we just not mention speed as a big deal in release notes and such. This also tied into the idea that managers don't worry too much about speed as much as being able to hire a bunch of Python programmers. This led to the suggestion of also emphasizing that Python is very easy to learn and thus is a moot point. There are a good number of Python programmers, though; Stephan Deibel had some rough calculations that put the number at about 750K Python developers worldwide (give or take; rough middle point of two different calculations). .. _article: http://gcn.com/vol1_no1/daily-updates/28026-1.html Contributing threads: - `2.4 news reaches interesting places <>`__ =============== Skipped Threads =============== - MS VC compiler versions - Any reason why CPPFLAGS not used in compiling? Extension modules now compile with directories specified in the LDFLAGS and CPPFLAGS env vars - adding key argument to min and max min and max now have a 'key' argument like list.sort - Unicode in doctests - SRE bug and notifications - PyInt_FromLong returning NULL - PyOS_InputHook enhancement proposal - The other Py2.4 issue - MinGW And The other Py2.4 issue - Supporting Third Party Modules - Python in education

1 0

Patch review [ 684500 ] extending readline functionality
by Michiel Jan Laurens de Hoon Jan. 19, 2005

Jan. 19, 2005

Patch review [ 684500 ] (extending readline functionality) This patch is a duplicate of patch [ 675551 ] (extending readline functionality), which was first submitted against stable python version 2.2.2. After the resubmitted patch [ 684500 ] against Python 2.3a1 was accepted (Modules/readline.c revision 2.73 and Doc/lib/libreadline.tex revision 1.16), the original patch [ 675551 ] was closed but patch [ 684500 ] was not. I have added a comment to patch [ 684500 ] that it can be closed. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

1 0