🌐 Mailman 3 December 2000 - Python-list - python.org

Programming with Python
by Simon B. Dec. 5, 2000

Dec. 5, 2000

I came across a Python book this weekend that I haven't heard of before - Programming with Python, by Tim Altom (see <http://www.prima-tech.com/book.asp?id=3942>). Anyone have this? Any good? -- Simon Brunning I think... I think it's in my basement. Let me go upstairs and check. - M.C. Escher Sent via Deja.com http://www.deja.com/ Before you buy.

5 8

A better python interface for buffer objects
by Paul Barrett Dec. 5, 2000

Dec. 5, 2000

I've just started working with buffer objects and noticed that they do not appear to be well supported at the python level, particularly for writeable buffer objects which I need. The string object exports a buffer interface, but only for read-only access. (Though if you test for the bf_getwritebuffer slot, it appears to be defined, indicating the string method is writeable. Only when you invoke this function does it return an error indicating that it's a read-only buffer. Is there a reason for implementing it this way, since I find this rather confusing?) Since I can't use a string object as a writeable buffer, is there some other object that I can use as a writeable buffer, not include that mmap object? What I'd like to do is just create a writeable buffer directly indicating the desired amount of memory, for example >>> buff = buffer(1024, 'w') I'm willing to supply patches to Python to support his type of functionality, if it can be agreed upon. -- Paul -- Dr. Paul Barrett Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Group FAX: 410-338-4767 Baltimore, MD 21218

2 2

Re: win32net - How to connect to a remote network share from a service
by David Bolen Dec. 5, 2000

Dec. 5, 2000

Mark Tompkins <mdtompkins(a)home.com> writes: > BTW, have you any suggestions as to specific Windows API documentation where > I might look, to gain a better understanding of the issues involved. In general, any of the stuff wrapped by the win32all modules is best served by the native Win32 documentation (as augmented with some Python specifics from the win32all documentation). The best place for this sort of documentation is the platform SDK (alone or as part of MSDN), which if you don't have a local copy is also available on the web at http://msdn.microsoft.com, or more specifically for the library documentation at: http://msdn.microsoft.com/library/default.asp This particular issue (impact of running services as LocalSystem on their network access) took me a day or two to locate the first time I ran into it with my own service (non-Python, not to mention first real Win32 application). Once I found the info it was pretty clear but I had a heck of a time figuring out what to search for :-) Here's a pointer to an MSJ article that provides some background: http://msdn.microsoft.com/library/periodic/period98/service2.htm and you might also look at the knowledge base articles Q122702, Q124184 and Q132679 (note that you'll have to select the knowledgebase from the search page to be able to look up these entries). -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l(a)fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/

1 0

Binary vs. Text mode
by Ben Mitchell Dec. 5, 2000

Dec. 5, 2000

Hello, I'm a little confused as to why, exactly, I'm seeing the following behavior and I'm hoping someone can clarify for me. First, assume I have a large xml-like file ("myfile") which has a tag </document> that appears alone on a number of lines throughout the file. I ran the following against that file: ----- import os import sys import string fp = open("myfile", "r+") while 1: justbefore = fp.tell() line = fp.readline() if not line : break line = string.strip(line) if line == "</document>": fp.seek(justbefore, 0) reread = fp.readline() print string.strip(reread) ---- Now it was my expectation that this would print out a whole bunch of lines that looked like: </document> </document> </document> </document> </document> </document> </document> ... Instead, I got: 5D 15E ocument> > nt> xt> ocument> cument> ocument> ument> ument> </url> <url> l> ument> ment> ocument> 16F ment> ument> nt> document> t> cument> /url> nt> ment> url> ument> cument> l> nt> cument> url> url> t> ent> cument> cument> cument> cument> cument> cument> ... When I then changed to opening in "rb+" mode instead of "r+", everything worked fine. This yields two questions. The first is why the byte offsets returned by fp.tell() vary depending on the read mode in which I've opened the file? Isn't it just returning a number of bytes from the head of the file? That doesn't vary, regardless of how the system perceives the data. The second question is the more perplexing one for me. It looks like, on a large enough number of instances that it's not random, the tell operation on a text mode opened file returned a location that was very close to where I expected it to be. (That's all those "ument>" and similar strings.) If in fact text mode is going to screw up the tell operation, shouldn't it *really* screw it up instead of getting it consistently close? In sum, I'd like to better understand the implications of opening in binary versus text mode. This is on a Windows box, btw. Thanks in advance for any clarification you can provide! Best, -Ben

3 3

Re: easy question on input files in Python
by robin.escalation＠ACM.org Dec. 5, 2000

Dec. 5, 2000

"Alex Martelli" <aleaxit(a)yahoo.com> wrote: >The one I like *least* goes: > >line = file.readline() >while line: > process(line) > line = file.readline() >file.close() Just a quick note that if performance matters, do not actually call another function to do the processing as process(line) shows. Do the processing in-line. This can make a huge difference due to the overhead of function calls. I know this from experience. Any experts know why the overhead is so great in Python? ----- robin robin(a)illusionsexeculink.com media artist / remove illusions to reply information architect www.execulink.com/~robin/ Isolation tank paves way to execute an attack.

1 0

controlling crashing Win9X apps ?
by Gregor Hoffleit Dec. 5, 2000

Dec. 5, 2000

Hi, luckily enough, I don't have profound experiences with Windows, but now I'm at the point where I have a Python script that walks down a directory tree and for each file calls a Win32 command line executable via os.system(). That all works well, but for a few files in the tree, the executable will crash and opens open up a modal panel ('close' or 'details') that blocks the script until I close a window (to be exact, the Win32 exe subsequently calls a few other exe's, and one of those crashes and blocks). Does Python on Win32 allow for some kind of process control that allows me to catch those errors and work around them ? Gregor

1 0

Re: Python programs (or scripts) as drop targets
by Alex Martelli Dec. 5, 2000

Dec. 5, 2000

"Mark Hammond" <MarkH(a)ActiveState.com> wrote in message news:3A2ACF21.4060406@ActiveState.com... > Alex Martelli wrote: > > > I think IDropTarget must be implemented somewhere in Mark's code, > > since *running* Python programs with win32all can be drop-targets. > > (Dunno about IPersistXXX, but that shouldn't be a big problem). But > > that doesn't necessarily help with implementing what you desire, i.e., > > making a *shortcut* into a droptarget. > > Actually, the other way of getting it for a running program is Windows > messages, and this is how win32all generally does it. Indeed, win32gui For a program that's *already* running, yes, there are several ways it can handle having stuff being dropped on it (though I think the COM solution is richer and more general). > could knock this up OK. It doesnt handle the "shell extensions" > features Dale pointed at, where a new object is instantiated to handle > the drop. Right -- you do need COM for that. > > But how this works for a _shortcut_ doesn't seem to be documented > > at all. > > I understand the shortcut is simply resolved using the other shell APIs > first. So one loses the precious information that the shortcut has in addition to the program-to-be-run, such as the flags, current directory, etc? Seems a suboptimal architecture to me (not that this would be the first suboptimal architecture in the Win32 API and surrounding subsystems, of course:-). > > One thing we could do is invent a "new filetype" to be used *instead* > ... > > To be quite honest, while I see that the "batch file" wrapper solution > isnt as "clean" as it could be, I don't believe a whole bunch of C++ > code or registry additions are worth saving this one trivial file. If saving a trivial file is indeed the only advantage of implementing the shell extension, then you may be right (though quibbling about the "registry additions" needed to _register_ a shell extension seems pretty peculiar to me). Alex

3 3

RE: problems with installer 20_3i
by Simon Brunning Dec. 5, 2000

Dec. 5, 2000

> From: gmcm(a)hypernet.com [SMTP:gmcm@hypernet.com] > Barry Scott just pointed out to me that the Python 2.0 imputil > does not by default install any method of importing builtins (even though > it installs, by default, a file system importer). > > Untested: at the top level of archive_rt (after the imports), put: > > sys.path.append(imputil.BuiltinImporter()) > > archive_rt will be imported by the C code long before your script runs, so > > builtins should be available. Gordon, Thanks for looking into the problem. I'm afraid though, that this fix doesn't work for me. Cheers, Simon Brunning TriSystems Ltd. sbrunning(a)trisystems.co.uk A man may be a fool and not know it, but not if he is married. - H. L. Mencken ----------------------------------------------------------------------- The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot accept liability for statements made which are clearly the senders own.

1 0

Re: PyThreadState_Get error again :(
by Robin Becker Dec. 5, 2000

Dec. 5, 2000

In article <3A2AD10F.8040803(a)ActiveState.com>, Mark Hammond <MarkH(a)ActiveState.com> writes >Robin Becker wrote: > >> I'm running BEOPEN Python 2.0, Win95 OSR2, PythonWin 134 (with the fixed >.pyds). > >I'm afraid that using "popen4("dir")" as the test, using ActivePython >201 (ie, win32all 135), on Windows 98, I can not get this code to fail >either from python.exe or pythonwin.exe :-( > >Mark. ... Well it's your co-author who claims it works with 2000 :) I can certainly 'claim' that there's something odd happening under win95. The good news is that we don't need the code any more ie we brought the calculation inboard. The crash happens when the output file is closed even when I try popen4("dir \\tmp"). The command seems to work and the output looks ok, just crashes when either of the files is closed. Is there any way to get 135 without reinstalling 2.0 or perhaps there has been a fix in that? Is it worth pursuing further? -- Robin Becker

2 2

Re: Python programs (or scripts) as drop targets
by Syver Enstad Dec. 5, 2000

Dec. 5, 2000

> So is there anyone out there with the VC++ skills sufficiently interested in this idea to code the > necessary interfaces? If there isn't support for doing this in python I could look into it. I've made a couple of shell extensions before that sounds pretty similar so it shouldn't be too much work. Can't you contact me Dale if we can't find a way to do this in Python?

3 3