Mailman 3 April 2001 - Python-Dev

Re: [Python-Dev] A kind of configuration question
by Moore, Paul April 9, 2001

April 9, 2001

On Thu, 5 Apr 2001, Cameron Laird wrote: > Why's there no Win* executable pydoc? There's an issue on Windows, because there are two types of executable (console and GUI). I've raised a bug report on this (407300), but the action taken was to remove the pydoc script (as opposed to the module) from the Windows installer, although there is still a start menu entry. The problem is that pydoc does two things - first, it starts a web server (with a small GUI control interface). This script needs … [View More]

2 2

Problems with zipfile.py
by James C. Ahlstrom April 8, 2001

April 8, 2001

The zipfile module seems to have been well received, and I have the impression that many people are using it. But I have been getting complaints that it won't read ZIP files created by InfoZip. At first I thought this was a problem with incompatible zlib compression versions, but now I have found the problem. It turns out that InfoZip's Wiz version 5.02 (and maybe other InfoZip versions) creates ZIP files with an incorrect value for "extra data length" in the central directory, but the … [View More]

2 1

FW: PyChecker - a python source code bug finder
by Tim Peters April 7, 2001

April 7, 2001

Way cool! Check this out. I picked 4 of the problems Neal found "at random", and all appear to still exist under current CVS. How about everyone take their favorite module and fix it? Thank you, Neal! -----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Neal Norwitz Sent: Saturday, April 07, 2001 2:28 PM To: python-announce-list(a)python.org; python-list(a)python.org Subject: PyChecker - a python source code bug finder … [View More]PyChecker is a python source code checking tool to help you find common bugs. It is meant to find problems that are typically caught by a compiler. Because of the dynamic nature of python, some warnings may be incorrect; however, spurious warnings should be fairly infrequent. Types of problems that can currently, be found include: * No doc strings in modules, classes, functions, and methods * self not the first parameter to a method * Wrong number of parameters passed to functions/methods * No global found (e.g., using a module without importing it) * Global not used (module or variable) PyChecker currently runs on Python 2.0. If there's interest, it can be back ported to Python 1.5.2. I have run PyChecker against Python 2.1b2a, the following are problems found in the standard python modules: ### Warnings codeop.py:3 Imported module (sys) not used codeop.py:4 Imported module (traceback) not used fileinput.py:292 Function (input) doesn't require named arguments multifile.py:30 Imported module (sys) not used pipes.py:62 Imported module (sys) not used urllib.py:598 Function (quote) doesn't require named arguments urllib.py:611 Function (quote) doesn't require named arguments string.py:190 Variable (_StringType) not used tabnanny.py:15 Imported module (string) not used imported again @ 241 and used there ### Errors: audiodev.py:214 No global (BUFFERSIZE) found bdb.py:111 No method (do_clear) found chunk.py:109 No attribute (chunk_size) found should be chunksize locale.py:253 No global (l) found netrc.py:13 No global (file) found pydoc.py:1070 No global (DocImportError) found pydoc.py:1070 No global (filename) found PyChecker is available on Source Forge: web page: http://pychecker.sourceforge.net/ project page: http://sourceforge.net/projects/pychecker/ Enjoy! Feedback is greatly appreciated. Neal -- pychecker(a)metaslash.com -- http://mail.python.org/mailman/listinfo/python-list [View Less]

1 0

[development doc updates]
by fdrake＠cj42289-a.reston1.va.home.com April 7, 2001

April 7, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Lots of small fixes, but also the first installment of the unittest documentation.

1 0

Re: [Python-Dev] A kind of configuration question
by Moore, Paul April 6, 2001

April 6, 2001

>[Moore, Paul] >> There's an issue on Windows, because there are two types of executable >> (console and GUI). I've raised a bug report on this (407300), but >> the action taken was to remove the pydoc script (as opposed to the >> module) from the Windows installer, although there is still a start >> menu entry. > >Paul, that action had nothing to do with your bug report. Ping managed to >break AMK's pydoc script on Windows the morning of 2.1b2 release … [View More]day, and >that left the Windows installer installing a non-functional Start menu link >for pydoc. Oh. Sorry about that - I seem to have misread your comments from when you reclosed the bug. I read them as "I've removed the scripts, so your bug no longer applies", rather than "the script needed to be removed, so ths issue has gone away". I apologise if I sounded critical. I do still think that being able to type "pydoc MODULE" at the command line would be very nice, and I feel that my batch file does this in a simple way. I'd be disappointed if it wasn't included in 2.1 (the whole pydoc suite appeared quite late, so minor fixes like this do get pushed up to the wire, but that doesn't necessarily mean they should be discarded as "too late"), but if it is deemed too late for that, could it be put into 2.2? On a related note, has anything happened on my other bug report (406280)? At the very least, using tempfilepager instead of pipepager as a workaround would be sensible. Leaving things broken makes no real sense. This is a patch: --- pydoc.py.orig Fri Mar 23 12:42:06 2001 +++ pydoc.py Fri Apr 06 10:56:02 2001 @@ -910,7 +910,10 @@ if not sys.stdin.isatty() or not sys.stdout.isatty(): return plainpager if os.environ.has_key('PAGER'): - return lambda a: pipepager(a, os.environ['PAGER']) + if sys.platform == 'win32': + return lambda a: tempfilepager(a, os.environ['PAGER']) + else: + return lambda a: pipepager(a, os.environ['PAGER']) if sys.platform == 'win32': return lambda a: tempfilepager(a, 'more <') if hasattr(os, 'system') and os.system('less 2>/dev/null') == 0: >> ... >> The other thing is to support the command line usage "pydoc XXX". > >Given that Win9x systems come with feeble cmdline shells (they're 50 lines >max, and no way to scroll back), I have no interest in pretending to support >pydoc's cmdline usage under Windows DOS boxes. Given that Windows NT/2000 command line shells are fine, and reasonably capable (including command history both at the prompt and within applications, whatever size you like, and scrolling buffers), refusing to support them just because 9x (which frankly is a dying environment for developers) is pathetic, is not a very helpful stance to take. I've supplied two low-impact patches which make pydoc work on the Windows NT command line. Sure, I can apply them manually to my installation, but why not make them available to everyone? frustrated-ly y'rs, Paul. [View Less]

4 4

Config problems in 2.1 for Digital Unix
by Cameron Laird April 6, 2001

April 6, 2001

Host: Digital Unix V4.0 (also Tru64 Unix 4.0G, also OSF1). Successful installation requires ./configure --with-cxx=gcc sed -e "s/-O -Olimit 1500/-O/" Makefile > /tmp/Makefile mv /tmp/Makefile Makefile The result of a plain configure is loading cache ./config.cache checking MACHDEP... osf1V4 checking for --without-gcc... checking for --with-cxx=<compiler>... no checking for c++... c++ checking whether the C++ compiler (c++ ) works... no configure: error: … [View More]

3 5

Re: [Pythonmac-SIG] __builtins__ a dictionary or a module?
by Jack Jansen April 6, 2001

April 6, 2001

Python-devvers, can anyone help with this behaviour? > If I run Just's Python IDE and run the same code it tells mes that > __builtins__ is a module. > > And finally if I run the following code from within the Interactive console > contained in standard 'code.py' file I get told __builtins__ is a > dictionary. > > So what is it? Is __builtins__ a module or a dictionary? I know that they're > essentially the same thing, but it unnerves me to have the same code … [View More]

2 1

Should Python #define _POSIX_THREADS?
by Jason Tishler April 6, 2001

April 6, 2001

Recently significant pthreads support has been added to Cygwin. When I attempted to build a Cygwin Python with threads, I got the following compilation error: gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Python/pythonrun.o Python/pythonrun.c In file included from /usr/include/signal.h:8, from Python/pythonrun.c:21: /usr/include/sys/signal.h:162: parse error before `thread' Cygwin's sys/signal has the following at line 162: #… [View More]

4 6

A kind of configuration question
by Cameron Laird April 5, 2001

April 5, 2001

Why's there no Win* executable pydoc? Let me know if I should ask this elsewhere. In part, I think I'm searching for larger generalizations that I'm particularizing with this specific instance. A Unix-side installation-from-source provides, along with much else, an executable /usr/local/bin/pydoc, whose content is simply #!/usr/bin/env python import pydoc pydoc.cli() As near as I can tell, installation of the 2.1 Python binaries for Win* gives no corresponding executable or "… [View More]

2 1

SF wierdness [Cygwin entry for README file]
by Neil Schemenauer April 5, 2001

April 5, 2001

Tim writes: > Assigned to me; deleted patch 4958 (Jason, whenever you try > to change something, it generally won't work unless you add > a comment at the same time -- don't know whether that's > what actually happened to you, but that's my best guess). Jason Tishler writes: > I *did add a comment! I always do! > > I'm using Netscape again, may be I should only use IE > whenever I submit SF patches. Sigh... Is it a browser issue or is it that only people on the … [View More]

3 3