Mailman 3 July 2006 - Python-Dev

test_uuid
by Neal Norwitz 30 Jul '06

30 Jul '06

Ping, I just checked in a change to disable testing 2 uuid functions (_ifconfig_get_node and unixdll_getnode) that fail on many platforms. Here's the message: """ Disable these tests until they are reliable across platforms. These problems may mask more important, real problems. One or both methods are known to fail on: Solaris, OpenBSD, Debian, Ubuntu. They pass on Windows and some Linux boxes. """ Can you fix these issues or at least provide guidance how they should be fixed? n

2 1

uuid test suite failing
by Georg Brandl 30 Jul '06

30 Jul '06

The UUID test suite, which wasn't run by regrtest.py until now, is now failing on some buildbots (and my machine). This should be fixed before releasing something. Georg

6 6

New miniconf module
by Sylvain Fourmanoit 29 Jul '06

29 Jul '06

I wrote a data persistence module called miniconf, aimed at making easy to create and safely retrieve configuration info from external, human-readable sources using Python syntax. I feel it would eventually make a nice addition to the standard library. The code was only newly refactored in this form, but it as been broadly distributed and used as a part of the adesklets project for over a year by a significant user base on multiple platforms. Here it is, as a patch against Python 2.5 SVN tree[1], or as a stand-alone module hosted on the Python Cheese Shop[2]; any feedback is welcomed. -- Sylvain <syfou(a)users.sourceforge.net> Hackers are just a migratory lifeform with a tropism for computers. [1]http://sourceforge.net/tracker/index.php?func=detail&aid=1527597&group_id… [2]http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1…

8 15

Using Python docs
by Georg Brandl 29 Jul '06

29 Jul '06

Regarding bug 469773, I think it would be great to have such a document "Using Python", containing the manual page and platform- specific hints on how to invoke the interpreter and scripts (e.g. explaining the shebang for Unices). I'd be willing to help write up such a document. Another thing that could be helpful is a list of "frequently needed documentation sections", that is, a list of keywords and respective links to topics that are hard to find for newbies, such as the section "String formatting" or some locations in the reference manual. Georg

1 0

Eliminating loops
by Charles Vaughn 29 Jul '06

29 Jul '06

I'm looking for a way of modifying the compiler to eliminate any loops and recursion from code. It's for a high speed data processing application. The alternative is a custom language that is little more than gloryfied assembly. I'd like to be able to use everything else around Python, but we can't allow the users to create more than O(1) complexity.

3 2

Re: [Python-Dev] patching pydoc?
by tomer filiba 29 Jul '06

29 Jul '06

> Giving the amount of hair-tearing over uuid and __index__, this seems like > an especially bad day to ask for a new-feature variance in a time of > feature freeze ;-). yeah, i guess so. > * Would making pager() a parameter of doc() make sense? not at all. > * I presume you gain the new functionality by directly calling the > factored-out render_doc and printing thru your own pager. Does everyone? i don't quite get the question, but yes, i plan to call render_doc instead of doc, getting the doc text, and printing it on my own console using a pager/whatever. about the signature, okay, it can easily be fixed. i didn't think about that too much. about the other point -- ImportError etc -- i tried to go "dumb" as much as possible and not make any change that would break something. pydoc is poorly written anyway, and as ron adam noted, there is a need for at least a cleaned-up version of pydoc, or even a redesigned package. and it ought to be a package. it's a module of ~2000 lines. that's way too much for a module. i made the minimal changes needed to separate the "generate text" part from the "generate and display" part. and i kept all the semantics in tact (including who handles the errors) and therefore, i don't expect it to break any tests (after restoring the original doc signature, that is). i'd hate to wait for 2.6 for such a small change. today my solution is to replace pydoc.pager by a fake pager that hands over the result. this is of course not thread safe, as multiple threads calling help() would mix their outputs. not very likely, but i'd love to see this code go away asap. thanks for the comments, -tomer > From: Terry Reedy <tjreedy <at> udel.edu> > Subject: Re: patching pydoc? > Newsgroups: gmane.comp.python.devel > Date: 2006-07-28 18:29:50 GMT (5 hours and 27 minutes ago) > > "tomer filiba" <tomerfiliba <at> gmail.com> wrote in message > news:1d85506f0607280635q3a693682l230c7821dc6f408f <at> mail.gmail.com... > ... > > therefore, i would like to split this behavior into two parts: > > * render_doc - a function that returns the document text > > * doc - a function that calls render_doc and sends it to the pager > > > > this way no existing code breaks (no existing function signatures > > are changed) and i gain help on remote objects. > > i hope people would be in favor, as it's not such a big change anyway. > > is it possible to add to 2.5? > > Giving the amount of hair-tearing over uuid and __index__, this seems like > an especially bad day to ask for a new-feature variance in a time of > feature freeze ;-). > > Some quick questions: > * I presume you gain the new functionality by directly calling the > factored-out render_doc and printing thru your own pager. Does everyone? > * Would making pager() a parameter of doc() make sense? > * Is pager() the only part of the original doc() that can generate > ImportError, ErrorDuringImport? If not, the try/except should be in > render_doc also or instead. > * Why generalize the doc() signature? Bad calls will be traced as caught > in render_doc instead of doc. Couldn't that potentially break a bad_call > test? > > Terry Jan Reedy

1 0

patching pydoc?
by tomer filiba 29 Jul '06

29 Jul '06

i have a problem with pydoc in rpyc. i wanted help(obj), where obj is a NetProxy object, to work as if it were local. i followed the code starting from site.help to pydoc.doc, which is the ultimate function that generates and prints the text. i expected there would be some function in the middle that prepares the text, and another that writes it to the pager, but to my disappointment pydoc.doc does both. this means i can't transfer the document to my local machine (it's printed directly to the remote console). therefore, i would like to split this behavior into two parts: * render_doc - a function that returns the document text * doc - a function that calls render_doc and sends it to the pager this way no existing code breaks (no existing function signatures are changed) and i gain help on remote objects. i hope people would be in favor, as it's not such a big change anyway. is it possible to add to 2.5? -tomer this is the code of pydoc, starting at line 1457 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< def doc(thing, title='Python Library Documentation: %s', forceload=0): """Display text documentation, given an object or a path to an object.""" try: object, name = resolve(thing, forceload) desc = describe(object) module = inspect.getmodule(object) if name and '.' in name: desc += ' in ' + name[:name.rfind('.')] elif module and module is not object: desc += ' in module ' + module.__name__ if not (inspect.ismodule(object) or inspect.isclass(object) or inspect.isroutine(object) or isinstance(object, property)): # If the passed object is a piece of data or an instance, # document its available methods instead of its value. object = type(object) desc += ' object' pager(title % desc + '\n\n' + text.document(object, name)) except (ImportError, ErrorDuringImport), value: print value >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this is the suggested code <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< def render_doc(thing, title='Python Library Documentation: %s', forceload=0): """generate the text""" object, name = resolve(thing, forceload) desc = describe(object) module = inspect.getmodule(object) if name and '.' in name: desc += ' in ' + name[:name.rfind('.')] elif module and module is not object: desc += ' in module ' + module.__name__ if not (inspect.ismodule(object) or inspect.isclass(object) or inspect.isroutine(object) or isinstance(object, property)): # If the passed object is a piece of data or an instance, # document its available methods instead of its value. object = type(object) desc += ' object' return title % desc + '\n\n' + text.document(object, name) def doc(*args, **kwargs): """Display text documentation, given an object or a path to an object.""" try: text = render_doc(*args, **kwargs) pager(text) except (ImportError, ErrorDuringImport), value: print value >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

3 3

Patch Against shutil.copytree Bug
by Michael Foord 29 Jul '06

29 Jul '06

Hello all, Sourceforge is being anal and won't let me log in. Attached is a patch for the shutil test, which would pickup bug "[1525866] Bug in shutil.copytree on Windows". It passes against a bug-fixed shutil [1] on my XP box, and fails on an un-fixed one. It only tests basic functionality of copytree. I did add tests that copystat had worked, but the mtime results were consistently off on Windows [2] so I removed that test. I would appreciate it if someone could post this patch to sourceforge. IMO this bug needs fixing before 2.5 final, the fix is trivial and shutil.copytree is broken on windows without it. All the best, Michael Foord [1] Bugfix supplied by Thomas Heller and is attached to the sourceforge bug report. [2] And consistently off in a weird way FWIW... 76a77,103 > > def test_copytree_simple(self): > src_dir = tempfile.mkdtemp() > dst_dir = os.path.join(tempfile.mkdtemp(), 'destination') > open(os.path.join(src_dir, 'test.txt'), 'w').write('123') > os.mkdir(os.path.join(src_dir, 'test_dir')) > open(os.path.join(src_dir, 'test_dir', 'test.txt'), 'w').write('456') > # > try: > shutil.copytree(src_dir, dst_dir) > self.assertTrue(os.path.isfile(os.path.join(dst_dir, 'test.txt'))) > self.assertTrue(os.path.isdir(os.path.join(dst_dir, 'test_dir'))) > self.assertTrue(os.path.isfile(os.path.join(dst_dir, 'test_dir', 'test.txt'))) > self.assertEqual(open(os.path.join(dst_dir, 'test.txt')).read(), '123') > self.assertEqual(open(os.path.join(dst_dir, 'test_dir', 'test.txt')).read(), '456') > finally: > try: > os.remove(os.path.join(src_dir, 'test.txt')) > os.remove(os.path.join(dst_dir, 'test.txt')) > os.remove(os.path.join(src_dir, 'test_dir', 'test.txt')) > os.remove(os.path.join(dst_dir, 'test_dir', 'test.txt')) > os.removedirs(src_dir) > os.removedirs(dst_dir) > except: > pass > >

1 0

Another uuid problem
by skip＠pobox.com 28 Jul '06

28 Jul '06

I just tried building and testing 2.5 on a Solaris 10 box at work. The uuid test failed with sh: ifconfig: not found sh: ifconfig: not found sh: ifconfig: not found sh: arp: not found sh: ifconfig: not found sh: ifconfig: not found sh: ifconfig: not found sh: arp: not found In our environment at least it's uncommon for /usr/sbin to be in the PATH of non-privileged users: piggy:% type -a ifconfig -bash: type: ifconfig: not found piggy:% PATH=$PATH:/usr/sbin type -a ifconfig ifconfig is /usr/sbin/ifconfig Perhaps test_uuid needs to do a little investigation to find ifconfig and arp. Skip

2 1

[Windows, buildbot] kill_python.c mystery
by Tim Peters 28 Jul '06

28 Jul '06

Rarely I'll be running the Python tests in my sandbox from a DOS box, and the test run will just end. Like so: C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py -uall -rw test_softspace test_codecmaps_kr ... test_float test_userdict C:\Code\python\PCbuild> No indication of success or failure -- the process just vanishes mid-stream. Today I noticed this happened when the buildbot started to run tests, and I'm 100% sure it's due to this code in Tools/buildbot/kill_python.c (the buildbot log files showed that kill_python.c killed /some/ Python process, and the Python running release-build tests in my sandbox was the only plausible candidate): if ((strstr(path, "build\\pcbuild\\python_d.exe") != NULL) || (strstr(path, "build\\python.exe") != NULL)) { printf("Terminating %s (pid %d)\n", path, pids[i]); if (!TerminateProcess(hProcess, 1)) { The second clause in the first `if` looks for a substring match on: build\python.exe and that just happens to match a suffix of: C:\Code\python\PCbuild\python.exe which is the release-build Python I happen to be running in my sandbox. Why is the second clause there? That is, are we /trying/ to kill a release-build Python running from the user's sandbox, and if so why? Introducing the second clause was the sole change in rev 46817, and the checkin comment doesn't really explain it: Port cygwin kill_python changes from 2.4 branch. Since I don't know what it's trying to accomplish, I hesitate to change it. It's quite clear what the first clause is trying to accomplish, and that one hasn't caused any problems.

4 4