Mailman 3 January 2004 - Python-Dev

Re: Relaxing Unicode error handling
by Aahz Jan. 3, 2004

Jan. 3, 2004

Martin: > > I'd like to add a static property unicode.errorhandling, which defaults > to "strict". Applications could set this to "replace" or "ignore", > silencing the errors, and risking loss of data. > > What do you think? Two traditional questions: * How does this work for library writers? * How does this work with threads? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

3 5

Head broken when --enable-unicode=ucs4 is used
by Barry Warsaw Jan. 3, 2004

Jan. 3, 2004

I've been building Python with --enable-unicode=ucs4 ever since I upgraded to RedHat 9. IIUC, this option is required to get Python and RH9's default Tk to play nicely together. The Python cvs trunk (i.e. 2.4) is broken when using this option. The pain starts immediately: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from Include/Python.h:82, from Modules/python.c:3: Include/unicodeobject.h:73:2: #error Must define Py_UNICODE_SIZE In file included from Include/Python.h:82, from Modules/python.c:3: Include/unicodeobject.h:131: parse error before "Py_UNICODE" Include/unicodeobject.h:131: warning: type defaults to `int' in declaration of `Py_UNICODE' Include/unicodeobject.h:131: warning: data definition has no type or storage class Include/unicodeobject.h:370: parse error before "Py_UNICODE" Include/unicodeobject.h:370: warning: no semicolon at end of struct or union Include/unicodeobject.h:375: parse error before '}' token Include/unicodeobject.h:375: warning: type defaults to `int' in declaration of `PyUnicodeObject' Include/unicodeobject.h:375: warning: data definition has no type or storage class [...continuing on for seemingly ever...] Without this switch, the compilation appears to work. I don't have time right now to investigate further, but if no one else can reproduce (or fix) this, I'll try to help out later. -Barry

2 2

python-dev Summary for 2003-12-01 through 2003-12-31 (rough draft)
by Brett Jan. 2, 2004

Jan. 2, 2004

python-dev Summary for 2003-12-01 through 2003-12-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from December 1, 2003 through December 31, 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 thirty-first and -second summaries written by Brett Cannon (a friend of a friend actually reads this thing! Hi, Elle). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. 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; it's 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-10-16_2003-11-15.html ===================== Summary Announcements ===================== Sorry if this summary comes off as light, but I caught the flu the week of Christmas and it developed into walking pneumonia which I still have. On a more positive note, PyCon is hitting its stride. Online registration is available at http://pycon.org/dc2004 and early bird registration ends January 31. Online talk proposal submission is online at http://submit.pycon.org/ and the deadline is January 15. ========= Summaries ========= ---------------------------- 2.3.3 released to the masses ---------------------------- `Python 2.3.3`_ has gone out the door. Thanks to Anthony Baxter for being release manager (again!) and to all of python-dev and anyone who contributed code for this release. With this being a bugfix release this supercedes 2.3.2 and thus people should upgrade if possible. .. _Python 2.3.3: http://python.org/2.3.3/ Contributing threads: - `2.3.3 cycle <http://mail.python.org/pipermail/python-dev/2003-December/040550.html>`__ - `release23-maint branch CLOSED for release <http://mail.python.org/pipermail/python-dev/2003-December/040852.html>`__ - `Berkeley support in release23-maint <http://mail.python.org/pipermail/python-dev/2003-December/041004.html>`__ - `RELEASED Python 2.3.3 (release candidate 1) <http://mail.python.org/pipermail/python-dev/2003-December/040740.html>`__ - `2.3.3 portability audit <http://mail.python.org/pipermail/python-dev/2003-December/041167.html>`__ - `2.3.3 and beyond <http://mail.python.org/pipermail/python-dev/2003-December/041183.html>`__ - `RELEASED Python 2.3.3 (final) <http://mail.python.org/pipermail/python-dev/2003-December/041286.html>`__ - `status of 2.3 branch for maintenance checkins <http://mail.python.org/pipermail/python-dev/2003-December/041424.html>`__ ---------------------------------- Pie-thon competition work ramps up ---------------------------------- `Dan Sugalski`_, project leader of the Parrot_ VM that will be used for `Perl 6`_, reminded the list that the benchmark to be used for the `Pie-thon`_ needed to be written since the bytecode for the benchmark needed to be frozen. So Guido wrote some benchmarks. They are in CVS under nondist/sandbox/parrotbench . .. _Dan Sugalski: http://www.sidhe.org/~dan/blog/ .. _Parrot: http://www.parrotcode.org/ .. _Perl 6: http://dev.perl.org/perl6/ .. _Pie-thon: http://www.sidhe.org/~dan/blog/archives/000219.html Contributing threads: - `Merry December <http://mail.python.org/pipermail/python-dev/2003-December/040613.html>`__ - `Pie-thon benchmarks <http://mail.python.org/pipermail/python-dev/2003-December/040963.html>`__ - `Pie-thon benchmark code ready <http://mail.python.org/pipermail/python-dev/2003-December/041527.html>`__ -------------- PyCon is a go! -------------- http://www.pycon.org/ has gone live! Registration_ is live (early-bird ends January 31)! Online talk proposal submission is live (deadline is January 15)! .. _Registration: http://www.pycon.org/dc2004 Contributing threads: - `PyCon DC 2004 - Registration about to open! <http://mail.python.org/pipermail/python-dev/2003-December/040553.html>`__ - `PyCon DC 2004 - Submissions Now Open <http://mail.python.org/pipermail/python-dev/2003-December/041012.html>`__ ---------------------------------------- operator gains attrgetter and itemgetter ---------------------------------------- The operator module has now gained two new functions: attrgetter and itemgetter "which are useful for creating fast data extractor functions for map(), list.sort(), itertools.groupby(), and other functions that expect a function argument" according to Misc/NEWS . Contributing threads: - `Re: "groupby" iterator <http://mail.python.org/pipermail/python-dev/2003-December/040590.html>`__ ------------------- CObjects and safety ------------------- Michael Hudson pointed out how CObjects could be misused in Python code. Various ideas of how to make them safer by checking that the proper CObject was passed were proposed. The thread seemed to end without a resolution, though. Contributing threads: - `are CObjects inherently unsafe? <http://mail.python.org/pipermail/python-dev/2003-December/040702.html>`__ ----------------- Unicode is a pain ----------------- Want proof? How about the fact that you can store a character like "√§" either as two characters ("a" followed by "previous character has an umlaut") or as one ("a with an umlaut"). The former is called "decomposed normal form" and is used in OS X. Windows, of course, uses the latter version. Contributing threads: - `test_unicode_file failing on Mac OS X <http://mail.python.org/pipermail/python-dev/2003-December/040778.html>`__ ------------------ Two new developers ------------------ Hye-Shik Chang has become a developer. You probably know him from his work on the CJK codecs. He is now an official developer. Vinay Sajip, implementor of the logging package has also been granted CVS checkin rights. Contributing threads: - `New developer <http://mail.python.org/pipermail/python-dev/2003-December/040808.html>`__ ------------------------ Compiling 2.4 under .NET ------------------------ Martin v. Löwis has started sandbox work on an MSI installer and moving Python 2.4 over to VC 7. Contributing threads: - `Py2.4 pre-alpha snapshot <http://mail.python.org/pipermail/python-dev/2003-December/040784.html>`__ - `First version of Python MSI available <http://mail.python.org/pipermail/python-dev/2003-December/041451.html>`__ - `Switching to VC.NET 2003 <http://mail.python.org/pipermail/python-dev/2003-December/041452.html>`__ ----------------------------- New method flag: METH_COEXIST ----------------------------- Raymond Hettinger, in his continual pursuit of speed, came up with a new method flag, METH_COEXIST, which causes a method to be used in place of a slot wrapper. The example that actually led to this is __contains__: a PyCFunction defining __contains__ tends to be faster than one in the sq_contains slot thanks to METH_O and other tricks. Contributing threads: - `FW: METH_COEXIST <http://mail.python.org/pipermail/python-dev/2003-December/040940.html>`__ ------------------------------ Better relative import support ------------------------------ There was a huge discussion on a better way to handle relative imports (think of the situation where you have your module ``import sys`` and you happen to have a module named sys in the same directory; should that local module be imported or the sys module from the stdlib?). Luckily Aahz volunteered to write a PEP on the whole thread so I am being spared from having to summarize the thing. =) Thanks, Aahz. Contributing threads: - `Re: Christmas Wishlist <http://mail.python.org/pipermail/python-dev/2003-December/040973.html>`__ - `Re: Python-Dev Digest, Vol 5, Issue 57 <http://mail.python.org/pipermail/python-dev/2003-December/041078.html>`__ - `Relative import <http://mail.python.org/pipermail/python-dev/2003-December/041065.html>`__ - `Another Strategy for Relative Import <http://mail.python.org/pipermail/python-dev/2003-December/041418.html>`__ ------------------------------ list.sorted becomes a built-in ------------------------------ Just as the title says, list.sorted has not been moved out of the list type and has been made a built-in. Contributing threads: - `python/dist/src/Python bltinmodule.c,2.304,2.305 <http://mail.python.org/pipermail/python-dev/2003-December/041129.html>`__ -------------------------------- What to do with old Python code? -------------------------------- Someone rewrote the bisect module in C. This brought up the question of what to do with the old Python version. Some suggest moving it to the Demo directory. Others suggest keeping the code but importing the C version in the Python module. The idea of keeping both was quickly shot down, though, like in the pickle/cPickle situation. This discussion is still going at this time. Contributing threads: - `SF patch 864863: Bisect C implementation <http://mail.python.org/pipermail/python-dev/2003-December/041511.html>`__

1 0

2.3.3 test_pty sometimes fails on Solaris
by Skip Montanaro Jan. 2, 2004

Jan. 2, 2004

I'm installing 2.3.3 on a Solaris 8 system. If I run "make test", it reports that test_pty failed and gives this error: test test_pty failed -- slave_fd is not a tty but if I run "./python Lib/test/test_pty.py" or ./python Lib/test/regrtest test_pty it seems the test succeeds. It smells sort of like the bug report at http://www.python.org/sf/864374. Any suggestions where I should look for culprits? I know zilch about ptys. Thx, Skip

1 0

RE: [Python-Dev] Pie-thon benchmark code ready
by Michael Chermside Jan. 2, 2004

Jan. 2, 2004

Samuele Pedroni writes: > at 0x<identity-hash-code> [is not unique], > at 0x<hex(id(.))> suggests to much the what comes after the 0x is the same > as what come after @ in the Java repr, which not being the case would be > confusing. Does "0x<hex(id(.))>" also have a performance problem? I seem to recall your saying that a bit of work needed to be done to make id() unique, and I thought I remembered that this work could be skipped whenever id() wasn't used. That's all well and good since id() is not used all that much, but __repr__ *WILL* be used all over the place. Of course, it's likely my recollections are incorrect. -- Michael Chermside

2 1

Re: [Python-Dev] Pie-thon benchmark code ready
by Samuele Pedroni Jan. 2, 2004

Jan. 2, 2004

>So I'd be happy if we could standardize on 'at 0x...' at least for all >objects where CPython currently uses that, letting implementations >choose what to put after the 0x, as long as it's hex digits. my proposal is that both the following forms should be acceptable: 1. <... at 0x<hex>> 2. <... id# <decimal>> and would change Jython to use the 2nd one. If we really want to just go with what is the status quo, i.e 1. then I would revert to use identityHashCode although it's not unique. regards.

1 0

regrtest.py mods for code coverage
by barry＠python.org Jan. 2, 2004

Jan. 2, 2004

Hi all, I wanted to improve the code coverage for base64.py (see previous message, re: RFC 3548 support) in the test_base64.py unit test. So I did a fairly simpleminded adaptation of Zope3's test.py -T code coverage flag to regrtest.py. Very handy for upping coverage of a module's code! The patch is available here: http://sourceforge.net/tracker/index.php?func=detail&aid=868499&group_id=54… Currently assigned to Jeremy for review. Please let me know what you think. -Barry

2 1

Re: [Python-Dev] Pie-thon benchmark code ready
by Samuele Pedroni Jan. 2, 2004

Jan. 2, 2004

> > At 14:52 01.01.2004 -0500, Tim Peters wrote: > > >IOW, CPython is enduring some pain to try to make this consistent too; > it's > > >not only Jython that can't get a free ride here. > >[Samuele] > > is not about having a free ride, it's just that printing the id(.) > > in Jython as a 'at 0x<hex-something>' is misleading because id(.) > > now is different from System.identityHashCode which is what goes > > into the java cls@<identity-hash-code> repr. > >I don't care either way. The importance of having *some* number here >is that for ordinary objects, if you print two different ones, the >repr() will show you that they are different, and if you print the >same one twice, repr() will show that too. I don't recall ever having >taken the id() of an object or the address from a repr() and looked it >up in memory using a debugger. > >OTOH if there's a way to get the Java runtime to print things like ><obj>@<addr> it might make sense to get Python's runtime to print the >same number after 'at'; in general giving developers a warm fuzzy >feeling of comfort through familiarity is good if it doesn't interfere >with other goals. yes, <addr> which is really <identity-hash-code> has that on its side but >>> import java.lang.System >>> _ihc = java.lang.System.identityHashCode >>> class C: ... def __repr__(self): return "<C obj at 0x%x>" % _ihc(self) ... >>> c=C() >>> c <C obj at 0x93a985> >>> d={} >>> for i in range(10000): ... new_c = C() ... ihc = _ihc(new_c) ... if d.has_key(ihc): ... print "clash" ... c = d[ihc] ... break ... else: ... d[ihc] = new_c ... clash >>> java.lang.Object.toString(c) 'org.python.core.PyInstance@e07d3e' >>> java.lang.Object.toString(new_c) 'org.python.core.PyInstance@e07d3e' >>> c <C obj at 0xe07d3e> >>> new_c <C obj at 0xe07d3e> >>> c is new_c 0 if we standardize on 'at 0x', then at 0x<identity-hash-code> has the above problem, at 0x<hex(id(.))> suggests to much the what comes after the 0x is the same as what come after @ in the Java repr, which not being the case would be confusing.

1 0

PEP 292 and templating
by Raymond Hettinger Jan. 2, 2004

Jan. 2, 2004

Is there interest in having a templating module with two functions one for simple substitutions and the other with more tools? The first would be Barry's simple substitutions using only $name or ${name} for templates exposed to the user. The second would extend the first with Cheetah style dotted names for more advanced templates controlled by the programmer. Raymond Hettinger

3 2

Re: [Python-Dev] Pie-thon benchmark code ready
by Samuele Pedroni Jan. 2, 2004

Jan. 2, 2004

At 20:44 31.12.2003 -0800, Guido van Rossum wrote: >But I've seen enough people write code that parses <...> reprs in some >way to make me think that maybe they should be standardized somewhat, >at least to the point where different Python implementations should >not differ gratuitously. E.g. Jython could be much closer to CPython >by inserting 'at 0x'. It's not like standardizing this would close >off an important implementation freedom for other Python >implementation. (I won't go as far as requiring that the number >should be the same as hex(id(x)). :-) btw in 2.1 there was no 0x (at least on Windows): Python 2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> class C: pass ... >>> C <class __main__.C at 007DE55C> >>> so in Jython: Jython 2.1 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> class C: pass ... >>> C <class __main__.C at 4862296> (and that number was not in hexadecimal) In the new world where Jython has a correct unique id: >>> class C: pass ... >>> C <class __main__.C 1> >>> 1 is id(C) but that's really not an address, so I'm not so keen in putting a 'at 0x' in there because is misleading and confusing cosidering the Java default repr for objects: java.lang.Object@ac7fbb which uses System.identityHashCode which is not unique, and is what we were using in Jython 2.1 (without going to hex). If I were to put an 'at 0x' in there, I would be tempted to revert to that value (System.identityHashCode) but given that is not unique and != id(.), it is rather less useful.

3 3