Mailman 3 September 2003 - Python-Dev

Re: [Python-checkins] python/dist/src/Objects unicodeobject.c, 2.197, 2.198
by M.-A. Lemburg Sept. 22, 2003

Sept. 22, 2003

tim_one(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory sc8-pr-cvs1:/tmp/cvs-serv17421/Objects > > Modified Files: > unicodeobject.c > Log Message: > On c.l.py, Martin v. Löwis said that Py_UNICODE could be of a signed type, > so fiddle Jeremy's fix to live with that. Also added more comments. Note that the implementation will bomb in several places if Py_UNICODE is a signed type. Py_UNICODE was never intended to be a signed type, so the proper fix would be to add logic so that Py_UNICODE gets forced to be an unsigned type. The only case where Py_UNICODE could become signed is via a compiler that defines wchar_t to be signed -- rather unlikely. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Sep 16 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

7 28

pep 310 (reliable acquisition/release pairs)
by Holger Krekel Sept. 22, 2003

Sept. 22, 2003

hello, admittedly i only followed Brett's very nice summaries (thanks!) in the last month so i may have missed some details. But here are a few comments regarding "PEP 310 Reliable Acquisition/Release Pairs". The PEP actually is about interacting with the execution of a code block. It allows to define (one-shot) interception points for entering and leaving a code block. Now there are at least two interesting cases which the PEP does (quite explicitely) not cover: - what to do with exceptions - what to do with yield IMHO introducing a new block statement at this stage in language development warrants an effort to tackle these cases (and maybe more like e.g. allowing the handler to trigger looping). This is probably best done with trying to directly design a protocol between the "interpreter-loop" and the - what i'd call - the "execution handler". And here it seems much more important to provide a concise definition of such a protocol (enter/leave/except/whatever) than to try to find an exact equivalence to plain python code. "Execution events" are really occuring at several points/bytecodes in the eval-loop and a plain python construct can only go so far. for example, you *could* say something like __enter__ called every time execution of the code block resumes (including when it is entered the first time) but this is not easily expressed in plain Python code although it seems implementable (and useful for resource-control when yielding). So while i am not strictly against the proposal i'd humbly ask for not hurrying into accepting the PEP as is. Python 2.4 is not closeby so i hope there is still some time to discuss this. I have done some practical experiments ("x-python") which actually incorporate XML-syntax into Python using a concept of an execution handler (tags are execution handlers and can additionally "catch" unassigned/dropped values that would otherwise be POP_TOPed). While this is impossible to ever appear in official Python i'd like to think about and report some experiences - but not before Novemeber because the next PyPy sprint and other stuff is keeping me far too busy. thanks & regards, holger

3 3

Py2.3.1
by Anthony Baxter Sept. 22, 2003

Sept. 22, 2003

I'm planning on starting the dance of the seven release tarballs Tuesday morning AU time, which is more or less 0:00 Tuesday UTC. Assuming that no-one objects to this timeframe, could people be _extremely_ conservative with checkins on the branch for the 24 hours before this? I'm going to be starting to cut test release tarballs probably some time tomorrow and building it on as many platforms as I can ssh to easily - I can make this available to other people if they want to help test, or if they've got some sort of strange version of Unix (Irix and HP/UX are always good ones to check for platform oddities). Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

5 8

2.3.1 windows binaries
by Thomas Heller Sept. 22, 2003

Sept. 22, 2003

For the 2.3.1 Windows binaries, I've followed the instructions in PCBuild\readme.txt and downloaded the sources for the additional packages. I have bzip2-1.0.2.tar.gz db-4.1.25.NC.zip tcl843-src.zip tk843-src.zip openssl-0.9.7b.tar.gz and zlib-1.1.4. All these versions are exactly those the readme file mentions, with the exception of openssl. Quote from the PCBuild\readme.txt: Get the latest source code for OpenSSL from http://www.openssl.org You (probably) don't want the "engine" code. For example, get openssl-0.9.6g.tar.gz not openssl-engine-0.9.6g.tar.gz Unpack into the "dist" directory, retaining the folder name from the archive - for example, the latest stable OpenSSL will install as dist/openssl-0.9.6g You can (theoretically) use any version of OpenSSL you like - the build process will automatically select the latest version. Is it important to use the same openssl version that Python 2.3.0 used, or is the readme file correct in saying that the latest version is the one to use? And does this have to be mentioned somewhere (Misc/NEWS, the readme file for windows)? Thomas

3 2

Pheromone sex attractant f qnzncjejaj nji
by Phil Travis Sept. 22, 2003

Sept. 22, 2003

1 0

Re: Fsrit Propttoye: SCLABMRE
by Michael Chermside Sept. 22, 2003

Sept. 22, 2003

Tihs drecvoisy souhld be supespserd imelidemtay... thnik waht it wlil do to SymaeapBs! -- Mcaeihl Chdemisre

1 0

Enhancement to pdb in gud.el
by Nick Roberts Sept. 21, 2003

Sept. 21, 2003

Hi, I've written a mode (gdb-ui.el) which is in the Emacs CVS repository (http://savannah.gnu.org/projects/emacs) that displays breakpoint icons in the display margin of Emacs when debugging with GDB. I can almost do the same thing for pdb (the Emacs interface to the python debugger in gud.el). Breakpoints in GUD can be set/cleared using the toolbar and it is easy to write a lisp function to do that. However, they can also be set/cleared from the GUD buffer with break/clear and gud-pdb-marker-filter is the best place to detect this. If I'm using pdb.py to debug fib.py and I type: (Pdb) b 4 I get the message: Breakpoint 1 at /home/nick/python/fib.py:4 and I can use gud-pdb-marker-filter to detect this string and insert a breakpoint icon at the appropriate line in the source buffer. Typing 'clear 1' gives Deleted breakpoint 1' and typing 'clear fib.py:4' gives no message and can't be detected. If, in both cases, the the message is modified to somthing like Deleted breakpoint 1 at /home/nick/python/fib.py:4 then I would have enough information. Anyone interested? Nick

2 1

Improving the CGI module
by Simon Willison Sept. 21, 2003

Sept. 21, 2003

Hi all, I've recently started using Python for server side web development, and I've been running in to some limitations in the CGI module. The most critical of these is that the module provides no method of determining whether form data originated in a query string (GET data) or a POSTed form. The module also provides very little in the way of support for common CGI related operations such as sending common headers and parsing and sending cookies; the Cookie module provides parsing capabilities but requires additional glue code to extract cookie data from the CGI environment. I have previous experience with PHP, which has a number of extremely convenient mechanisms for dealing with form input and cookies that I sorely miss when working with Python. I have started work on porting some of these capabilities, but it struck me that several of the ideas represented would make valuable additions to the Python standard library itself. I have been working with Python for over a year, but I have no real experience of the Python development process. Is this list the right place to discuss potential improvements to the CGI module, or should I work independently and construct a PEP? I noticed that PEP 222 already exists relating to "web library enhancements", but it has a 'Deferred' status and appears not to have been modified since December 2000. Best regards, Simon Willison http://simon.incutio.com/categories/python/

8 7

python-dev Summary for 2003-09-01 through 2003-09-15 [draft]
by Brett C. Sept. 19, 2003

Sept. 19, 2003

Not planning on rushing this summary out the door; most likely will send it out on Sunday. So have a read and show me why I should not pass the writing test I have to take next month that is supposed to prove I am a competent writer. --------------- python-dev Summary for 2003-09-01 through 2003-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from September 1, 2003 through September 15, 2003. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-fifth summary written by Brett Cannon (with school looming on the horizon). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on something mentioned here. PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-08-16_2003-08-31.html ===================== Summary Announcements ===================== Summary is nice and short this time. More people went on vacation (although Martin came back and so that helped to pick up the traffic a little). I skipped covering some threads that are due for PEPs since those will be more in-depth then anything I write. I should give fair warning that starting on the 22nd of September I will begin school. I am hoping that it will not be difficult and I will have a carefree time in school. But if my workload becomes a burden the Summaries might suffer. I hope they don't, though, and I am going to do my best to make sure that doesn't happen. ========= Summaries ========= --------------------------------------- If It Isn't Documented, Is It a Secret? --------------------------------------- Some undocumented methods in readline were discovered by Philip Eby. He asked if this was on purpose and whether he should submit a bug report on the lack of documentation. Guido told him to go ahead and submit the bug report. If you ever find something undocumented in the Python source code and there is nothing suggesting the code is meant to be hidden from the user (it's for internal use, a comment says it is experimental, etc.), then please file a bug report! Contributing threads: - `Undocumented functions in 'readline' module <http://mail.python.org/pipermail/python-dev/2003-September/037922.html>`__ ----------------------------------------------------------------------------------------- "You are more trouble than you are worth!", screamed the micro release to the new feature ----------------------------------------------------------------------------------------- The topic of what should be backported for micro releases (with Python 2.3.1 looming on the horizon) came up. Originally minor improvements were allowed in if they didn't break backwards compatibility. And of course bugfixes have been as well as long as they didn't break code that came to depend on the buggy behavior (really depends on how long the bugginess has been there and how well-known it is). But then the point of OS X 10.3 possibly becoming the largest install base of Python of any version (it will be 2.3) came up. With rough estimates being thrown around of 5 million installs in about a year's time, the point that making it difficult to run Python 2.3.x code on that size of an install base would be bad. For instance, if some small new feature was added to 2.3.1 then any code using that feature would not be able to run on a virgin install of OS X 10.3 (and considering that this is Mac it should not be expected that most users will want to, let alone know how, to add a secondary install of Python since the original is used by the OS and thus should not be overwritten). It looks like a more conservative patching scheme will be taken with micro releases. Bytecode will also continue to work between releases. Guido has always unofficially held that position but now it has been vocalized. Contributing threads: - `Documenting branch policy <http://mail.python.org/pipermail/python-dev/2003-September/037955.html>`__ ---------------------------------------------- PyPy "Berlin" sprint (29th Sep - 4th Oct 2003) ---------------------------------------------- Just what the title says: there is going to be a sprint_ for PyPy_ in Berlin from September 29 to October 4. Read the email for more specific details on goals and such. .. _sprint: http://www.python.org/cgi-bin/moinmoin/SprintPlan .. _PyPy: http://codespeak.net/pypy/index.cgi?home Contributing threads: - `PyPy "Berlin" sprint (29th Sep - 4th Oct 2003) <http://mail.python.org/pipermail/python-dev/2003-September/037961.html>`__ -------------------------------- Away with you ambiguous imports! -------------------------------- A discussion on how to create a hierarchy of loggers in the standard library led to the idea of having a way to cause an import to come directly from the standard library and thus remove any ambiguity from a relative import grabbing a similarly named module from the local package. Barry Warsaw he was thinking of writing a PEP on this idea. Contributing threads: - `Consistent logging in the standard library <http://mail.python.org/pipermail/python-dev/2003-September/038000.html>`__ --------------------------------------------------- Quick: want to give a Python talk at Linuxworld NY? --------------------------------------------------- If you are interested in what the title asks, then read the email for some details. Contributing threads: - `Quick: want to give a Python talk at Linuxworld NY? <http://mail.python.org/pipermail/python-dev/2003-September/037993.html>`__ ------------------------------------------- Be careful about saying something is "easy" ------------------------------------------- A word of advice about saying something is "easy" on python-dev: if you say that you should make sure you can back up that claim because otherwise you will be told to write the "easy" patch and that will be the end of the discussion. Contributing threads: - `Making python C-API thread safe (try 2) <http://mail.python.org/pipermail/python-dev/2003-September/038007.html>`__ -------------------------- Parsing dates for datetime -------------------------- There was some talk about coming up with some code to parse dates for the datetime module. It was kind of hand-wavy since there are multiples chunks of code that can do that in the standard library. If you have an opinion on this (or anything for that matter), make sure to make a post to `comp.lang.python`_ about it. Contributing threads: - `datetime issues <http://mail.python.org/pipermail/python-dev/2003-September/038042.html>`__

2 2

Re: [Python-Dev] Fsrit Propttoye: SCLABMRE
by Kevin J. Butler Sept. 19, 2003

Sept. 19, 2003

I agilzoope bceasue I msiesd rnaiedg your msagese unitl I saw a rlepy. I'm delgehitd taht you are cientarg a cnompay to exiplot tihs marouvles pnmenoehon. If you are looikng for aiidndotal team mebmers for yuor work snrlibcmag txet, I simbut this, the paorrgm I wtore when I haerd of this ireesttnnig and ueufsl (or mbaye jsut ireeitsnntg) eefcft. I hope it metes wtih yuor approval, tuhgoh wehn tarteed wtih ilestf (and a maoterde aomunt of uesr ivtintorenen, it lsot sangtcniilfiy more rlaaitebdiy than the visoern wtriten in the other 'P' luangage. Stetrad wtih more, lsot more, raetenid mroe...). In-serbmclad-txet-ly y'rs kb """ Srbmlcae by Kiven Beultr 2003 pthyon-kbuletr(a)sdabayi.com Rlaseeed into pibulc dmioan wtih no wrtanray Use at yuor own rsik """ import sys import random import re def srbmlcae( wrod ): ieiedsns = list( wrod[1:-1] ) random.shuffle( ieiedsns ) return wrod[0] + ''.join( ieiedsns ) + wrod[-1] def scRbaelmrx( match ): return srbmlcae( match.group() ) for lnie in sys.stdin: print re.sub( "\w{4,}", scRbaelmrx, lnie )[:-1]

1 0