Mailman 3 April 2002 - Python-Dev

test_inspect failure
by Tim Peters 21 Apr '02

21 Apr '02

I'm seeing test_inspect.py fail on Windows, but only when run under regrtest: C:\Code\python\PCbuild>python ../lib/test/regrtest.py -v test_inspect.py test_inspect test test_inspect crashed -- exceptions.IndexError: list index out of range Traceback (most recent call last): File "../lib/test/regrtest.py", line 315, in runtest File "../lib/test\test_inspect.py", line 167, in ? git.abuse(7, 8, 9) File "@test", line 39, in abuse self.argue(a, b, c) File "@test", line 46, in argue self.tr = inspect.trace() File "C:\CODE\PYTHON\lib\inspect.py", line 782, in trace File "C:\CODE\PYTHON\lib\inspect.py", line 763, in getinnerframes File "C:\CODE\PYTHON\lib\inspect.py", line 717, in getframeinfo File "C:\CODE\PYTHON\lib\inspect.py", line 413, in findsource IndexError: list index out of range 1 test failed: test_inspect C:\Code\python\PCbuild> It's certainly curious that the traceback is missing all the code lines from inspect.py! Even curiouser, when run directly, no problem: C:\Code\python\PCbuild>python ../lib/test/test_inspect.py C:\Code\python\PCbuild> I'm using stock CVS, + defining WITH_UNIVERSAL_NEWLINES. This is suspicious, because when run under regrtest, test_inspect gets imported, and then universal newlines kicks in (if I understood the PEP); I'm not clear on whether universal newlines kicks in when a file is run directly. Is anyone else with universal newlines (or without, for that matter ...) seeing test_inspect fail?

2 6

Weekly Python Bug/Patch Summary
by Skip Montanaro 21 Apr '02

21 Apr '02

Bug/Patch Summary ----------------- 233 open / 2432 total bugs (-6) 97 open / 1438 total patches (+4) New Bugs -------- gcc warning in unicodeobject.c (2002-04-15) http://python.org/sf/544248 gcc warning in Modules/readline.c (2002-04-15) http://python.org/sf/544265 test_commands test fails under Cygwin (2002-04-16) http://python.org/sf/544740 Internet Config -666 error (2002-04-17) http://python.org/sf/545059 walk() walks aliases (2002-04-17) http://python.org/sf/545388 corefile: python 2.1.3, zope 2.5.0 (2002-04-17) http://python.org/sf/545410 py-execute-string doesn't work (2002-04-17) http://python.org/sf/545436 IDLE doesn't save 8bit files (2002-04-18) http://python.org/sf/545600 cannot save buffer (2002-04-18) http://python.org/sf/545655 Wrong exception from re.compile() (2002-04-18) http://python.org/sf/545855 regex segfault on Mac OS X (2002-04-19) http://python.org/sf/546059 IDLE calltips cause application error (2002-04-19) http://python.org/sf/546078 readlines() bombs - last line incomplete (2002-04-19) http://python.org/sf/546117 load_false/true() not used (2002-04-19) http://python.org/sf/546156 extend namespace docs to cover LOAD_NAME (2002-04-19) http://python.org/sf/546196 buffer slice type inconsistant (2002-04-20) http://python.org/sf/546434 Windows getpass bug (2002-04-20) http://python.org/sf/546558 Nested anchors in Ref Man index.html (2002-04-20) http://python.org/sf/546579 New Patches ----------- test for patch #543865 & others (2002-04-14) http://python.org/sf/543867 merging sorted sequences (2002-04-15) http://python.org/sf/544113 addition of cmath.arg function (2002-04-16) http://python.org/sf/544909 Janitoring in ConfigParser (2002-04-17) http://python.org/sf/545096 {a,b} in fnmatch.translate (2002-04-17) http://python.org/sf/545150 sgmllib support for additional tag forms (2002-04-17) http://python.org/sf/545300 interactive help in python-mode (2002-04-17) http://python.org/sf/545439 Examples for urllib2 (2002-04-17) http://python.org/sf/545480 make test_linuxaudiodev ignore EBUSY (2002-04-17) http://python.org/sf/545486 patch for 514433 bsddb.dbopen (NULL) (2002-04-18) http://python.org/sf/545523 implementation of Text.dump method (2002-04-19) http://python.org/sf/546244 Closed Bugs ----------- Extension manual: Windows DLL/C++ info needs review (2000-12-08) http://python.org/sf/225003 ConfigParser.options return default opts (2001-07-14) http://python.org/sf/441279 Py closes COM instances not loaded by Py (2001-09-06) http://python.org/sf/459160 test_time fails on Sparc64 (2001-09-10) http://python.org/sf/460357 Build troubles: --with-pymalloc (2001-12-20) http://python.org/sf/495401 smtplib.py AUTH mechanism (2002-01-02) http://python.org/sf/498572 free vars sometimes show up in locals() (2002-01-18) http://python.org/sf/505315 Py_CompileString and tracebacks (2002-01-23) http://python.org/sf/507477 Ellipsis semantics undefined (2002-02-17) http://python.org/sf/518985 compiler/transformer.py STARSTAR doesn't exist (2002-02-24) http://python.org/sf/522274 NameError assigning to class in a func (2002-03-20) http://python.org/sf/532860 SMTPLib sendmail fails on hyphenated adr (2002-03-31) http://python.org/sf/537484 PyType_GenericNew broken (2002-04-08) http://python.org/sf/540965 link to index.html from modindex.html (2002-04-08) http://python.org/sf/541257 IDLE can clobber files (2002-04-09) http://python.org/sf/541730 delattr() causes python to segfault (2002-04-09) http://python.org/sf/541883 urllib.urlopen throws OSError (2002-04-10) http://python.org/sf/541980 allow use of descriptors for __doc_ attr (2002-04-12) http://python.org/sf/542984 SocketServer initializing outbound UDP (2002-04-12) http://python.org/sf/543318 pdb: contradictory msg for "exit"/Ctrl-D (2002-04-14) http://python.org/sf/543674 Closed Patches -------------- new base class for binary packaging (2001-04-10) http://python.org/sf/415226 Solaris pkgtool bdist command (2001-04-10) http://python.org/sf/415227 HP-UX packaging command (2001-04-10) http://python.org/sf/415228 Additions & corrections to libmacui.tex (2001-12-25) http://python.org/sf/496705 Work around for buggy https servers (2002-01-07) http://python.org/sf/500311 string.zfill and unicode (2002-03-28) http://python.org/sf/536241 Remove PyMalloc_* symbols (2002-04-06) http://python.org/sf/540394

1 0

PEP 263 update (source encodings)
by martin＠v.loewis.de 19 Apr '02

19 Apr '02

Since Mr. Suzuki proposed a patch for phase 2 of PEP 263, I've been thinking that the implementation could go right away to phase two; skipping my implementation of phase 1. Still, providing the transitional warning of phase 1 is desirable, and indeed possible with this implementation. So after discussion with MAL, I have updated the PEP to reflect this strategy. There are only minimal user-visible changes: - more encodings can be supported even in phase 1, in particular those based on ISO 2022 (provided that the proper codecs are available) - it is now an error if the declared encoding and the text do not match. If there is no encoding declared, it is still only a warning if you then use non-ASCII bytes. More interesting is the change to the implementation strategy: the parser will create a codecs.StreamReader to obtain the input, and will convert each line to UTF-8; parsing then operates on the UTF-8 strings. This has the advantage that all lexical processing can still use the same char*, interpreted as ASCII, as before. The declared encoding is preserved (as in my stage 1 implementation), in order to recode string literals back to the original encoding. Anybody familiar with the parser is encouraged to review this code; see http://python.org/sf/534304 http://python.org/peps/pep-0263.html Regards, Martin

1 0

Re: [Python-Dev] Adding Optik to 2.3 standard library
by Anthony Baxter 19 Apr '02

19 Apr '02

>>> Guido van Rossum wrote > > Hm. I also want to work with tar and tar.gz files. Is there any > > intend to add a tarfile module to the Python library? > > Dunno, but it's a pretty simple format, so should be easy. Maybe one > of the rookie developers would like to tackle this? If it's wanted, I have a cpio reader class somewhere that could be thrown in. Note that (from memory) it only handles some of the many, many different cpio formats... -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

8 8

POTTERY
by CERAMICA MEJIAS POLONIO C.B. (SPAIN) 19 Apr '02

19 Apr '02

Dear Sirs Our company´s name is "Cerámica Mejías Polonio". We manufacture hand-made pottery for decoration. We would like to offer you our articles which you can see on our web-site www.myempresa.com/mejiaspolonio We are already exporting to some European and Asian countries where our articles are very successful due to their good finishing and difference in style. We hope you like our articles. If you want to contact us you can do it at: "Cerámica Mejías Polonio C.B." C/Carrera Baja,22 14540 La Rambla (Cordoba) Spain. Phone/fax: +34 957 682 280 Translator´s contact: +34 650 06 02 79 e-mail: mejiaspolonio(a)teleline.es web: www.myempresa.com/mejiaspolonio Waiting for your news. Yours Faithfully.

1 0

CVS/syncmail/SF
by Skip Montanaro 19 Apr '02

19 Apr '02

Sorry for the not-quite-Python-related question, but where do I checkout syncmail on SF if I want to use it like so from CVSROOT/loginfo: DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv} largefiles-checkins(a)lists.sourceforge.net In the "getting email from CVS" page it says: After you've handled the checkout a working copy of syncmail into the repository, you need to modify your CVSROOT/loginfo file to tell CVS to invoke syncmail for all the interesting events CVS is willing to tell us about. I poked around all the SF docs that looked obvious without any luck. I also ssh'd into shell.sf.net and largefiles.sf.net but found no /cvsroot/largefiles directory on either. I posted a SF support request a few hours ago, but haven't heard anything from them. From the looks of the number of support requests open, I anticipate a lengthy wait. Where am I supposed to checkout a working copy of syncmail? I presume it has to be on a SF machine somewhere, but I've been unable to figure out where. Thx, Skip

4 3

A better index for Python manuals?
by Thomas Heller 19 Apr '02

19 Apr '02

Would it be possible to create a "better" index for Python manuals? For example, show the page-number/link in bold where an api-function is defined instead of only mentioned... There are several tools now which scan the HTML index to build lists of keywords, they can't get too many information from entries like this: Py_Finalize(), [Link], [Link], [Link], [Link], [Link] Thomas

2 1

Re: tarfile
by Gustavo Niemeyer 18 Apr '02

18 Apr '02

Hi Lars! > > Itamar told me about some changes he submitted to zipfile, and weren't > > accepted by lack of documentation and unittests. Here is an excerpt of > > his message: > [...] > > Could you please review it!? > > I had a look at it and IMO it's the right way. Too bad that the patch > did not succeed. I started to include a similar method today replacing > the readstr() method. The same will follow with writestr(). Thanks! > But OTOH this does not solve the problem I described in my last message: > >> [...] > >> When using tarfile the user assumes that all of > >> the meta-informations of a file like mode, ownership, modification > >> time etc. are extracted as well, for example when restoring a backup. > > We should find a solution to that, most of the code of tarfile deals > with these particular tasks... What do you think about keeping the current zipfile semantics of read/write returning strings, and using your suggesion of extract() and add() to implement the new functionality of dumping to disk? We could even have some kind of Dumper class, which would be responsible for that task, and could be replaced by the user if necessary (personaly, I'm not against something like "read = extractstr" as well). > > I understand your position, and agree with you. Nevertheless, we should > > let the interface as close as *possible*. If zipfile is not well > > designed, I'd like to change it as well. > >From my (insignificant) point of view, I would not care too much about > standardization in this particular case, because the "standard" > introduced by the zipfile module is *very* *very* limited. Yes, zipfile.py interface's is not a nice example for a global interface for file storing. > I think we don't do ourselves a favour if we take zipfile's interface > as a basis. And I think we don't do the user a favour because he would > always tend towards mixing up both interfaces, which would both be > somehow similar but OTOH fundamentally different. > > Wouldn't it be good to do it the opposite way round and create a solid > interface for tarfile, which could be used as a basis for a > new/patched zipfile or perhaps some day for other archiver-related > modules? Yes, it'd be nice indeed, but I wouldn't like to see, for example, a cpio handler with a different interface in the future, because the current ones don't fit well for the task. You told me you were willing to write a PEP. Is that PEP about tarfile specific issues, or a general interface for that kind of job? > I mention again the small TarFileCompat class I wrote within 5 > minutes, which perfectly emulates a ZipFile class. Try that > the other way 'round and you're sold down the river... I understand.. > I apologize deeply for my obstinacy.... But I can't help myself. > Please tell me, if I exaggerate or if I am wrong. But at the moment I > don't have any idea how to be "as close as possible" to zipfile, > sorry. Again, you've done a great job with tarfile so far, and I'm thankful for that. I'm sure we can handle those issues and still have something you're proud of. Btw, I've notice TarInfo is using class attributes on initialization. Wouldn't instance attributes reflect better their meaning? Thanks! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

2 1

Transaction
by Andy Robinson 18 Apr '02

18 Apr '02

> claim consignment NO: 1201 containing US$ 9,000,000.00 > and consignment NO: 1200 containing US$ 12,000,000.00. > I will suggest upon conclusion, 30% goes to you and > 70% for me. At the successful completion of the deal, > you will arrange for me and family to come over to > your country. If you can persuade the INS that this guy is a uniquely qualified release manager and get hima green card, it could fund a LOT of backporting and release management :-) - Andy

1 0

Significance of informational PEPs
by Andrew Kuchling 18 Apr '02

18 Apr '02

With Barry's approval, I've just checked in a minor change to PEP 1 that clarifies the significance of information PEPs: diff -u -r1.31 pep-0001.txt --- pep-0001.txt 5 Apr 2002 19:42:56 -0000 1.31 +++ pep-0001.txt 18 Apr 2002 16:26:32 -0000 @@ -35,7 +35,9 @@ new feature or implementation for Python. An informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new - feature. + feature. Informational PEPs do not represent a Python community + consensus or recommendation, so users and implementors are free to + ignore informational PEPs or follow their advice. If people disagree about this view of informational PEPs as purely advisory, please speak up now so we can discuss this issue. (This came up because of the recently-posted PEP 272. Some people on the python-crypto list don't like PEP 272's interface at all, and other people think the whole idea of a standard API for block encryption is useless. It seems impossible to come to consensus, so I wanted to underscore that informational PEPs don't bind people to the interfaces they describe.) --amk (www.amk.ca) I was continually connected with the whole world and never got any rest. At the moment, I spend only a few hours weekly on the net, that's just better for me. -- Peter Greenaway, in an interview in _Page_, May 1999

4 7

Python-Dev April 2002