Re: return a value to shell script
devi thapa wrote: > I am executing a python script in a shell script. The python script > actually returns a value. > So, can I get the return value in a shell script? If yes, then help me > out. Yes. The variable $? should be bound to the return value of the last foreground program to exit. The python script can return a value using sys.exit(value) HTH -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: matplotlib question
asdf wrote:
> basically I need to plot a graph of data vs time. However when i use
> matplotlib the hr:min tick marks come out very close together and
> appear jumbled.
You need to look up the matplotlib.dates package - it's covered briefly in
the tutorial at http://matplotlib.sourceforge.net/tutorial.html
At a guess, you want something along the lines of this...
from matplotlib.dates import YearLocator, MonthLocator, WeekdayLocator, \
DayLocator, HourLocator, MinuteLocator, SecondLocator, \
DateFormatter
subplot.xaxis.set_major_locator(HourLocator(range(0,24,6)))
subplot.xaxis.set_major_formatter(DateFormatter("%a %H:%M"))
subplot.xaxis.set_minor_locator(HourLocator(range(0,24,1)))
...but you'll probably need to look up the documentation to get the details
to suit what you need.
Hope that helps!
--
I'm at CAMbridge, not SPAMbridge
--
http://mail.python.org/mailman/listinfo/python-list
Re: Licence confusion: distributing MSVC?71.DLL
jim-on-linux wrote: > This is what someone wrote on 1-21-2007 > to this help site about this pain in the a... > MSVCR71 stuff. > > " I believe this problem doesn't exist. > (snip useful bit of EULA and explanation) Thanks for that - just what I didn't manage to turn up with Google. I'll go ahead and publish then :-) -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Licence confusion: distributing MSVC?71.DLL
Gabriel Genellina wrote: > Maybe this thread > http://groups.google.com/group/comp.lang.python/browse_thread/thread/f8df5ed32b324a3f/ > can help. > > This EULA doesn't apply to you, but to the Python developers, which are > the actual Visual Studio users and have to comply with its license terms. > You're just repackaging Python, your program, and other required > components. > In any case, I don't think MS cares; after all, you're promoting their OS > and making life easier for Windows users. Many thanks - that does indeed answer it. I'd not been able to find the EULA, but the bits quoted from it in the above discussion do answer the question. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Licence confusion: distributing MSVC?71.DLL
Tom Wright wrote: > If someone has worked their way through this maze before and has an > answer, I'd be keen to hear it. Hmm, an answer of sorts: Inkscape's Windows build comes with MSVCR70.dll and MSVCR71.dll (but not MSVCP71.dll). As it's a big and high-profile project distributed under GPL2, I think they must've done their homework. Let's hope I'm ok in slightly different circumstances: distributing MSVCP71.dll as well, and under GPL3. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Licence confusion: distributing MSVC?71.DLL
Hi I've written a program in Python using wxPython and Matplotlib and would like to distribute it under the GPL. For ease of use, I'd also like to distribute and installable version for Windows, but this needs MSVCR71.dll and MSVCP71.dll to work. I've created an installer using py2exe and Inno Setup but I don't know if I'm allowed to distribute it or not. I've found lots of conflicting opinions online indicating that I can or cannot distribute these, but no definitive answer. The Microsoft Developer Network instructs me to read the redistribution instructions and the EULA which come with Visual Studio, but I don't have visual studio, so that's next to useless. If someone has worked their way through this maze before and has an answer, I'd be keen to hear it. Failing that, if you have Visual Studio and it's not a violation of the licence terms to post the licence and redistribution instructions here, could you possibly do so and I'll see if I can work out what's allowed. Thanks! -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: recursion
Gigs_ wrote: > Can someone explain me this > def f(l): > if l == []: > return [] > else: > return f(l[1:]) + l[:1] # <= cant figure this, how is > all sum at the end? If you think about building up from the simplest case: f([]) = [] f(['a']) = f([]) + ['a'] = [] + ['a'] = ['a'] Now f(['a', 'b']) is going to be: f(['b']) + ['a'] = ['b'] + ['a'] = ['b', 'a'] Similarly, for f(['a', 'b', 'c']), that will be: f(['b', 'c']) + ['a'] Of course, if you want to do this you can always use list.reverse() but I guess you're trying to get a handle on recursion rather than just reverse a list. I find thinking up from the base case helps when trying to understand recursive code but when writing it, I tend to work the other way around. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
[EMAIL PROTECTED] wrote: > If your program's behavior is: > > * allocate a list of 1e7 ints > * delete that list > > how does the Python interpreter know your next bit of execution won't be > to repeat the allocation? It doesn't know, but if the program runs for a while without repeating it, it's a fair bet that it won't mind waiting the next time it does a big allocation. How long 'a while' is would obviously be open to debate. > In addition, checking to see that an arena in > the free list can be freed is itself not a free operation. > (snip thorough explanation) Yes, that's a good point. It looks like the list is designed for speedy re-use of the memory it points to, which seems like a good choice. I quite agree that it should hang on to *some* memory, and perhaps my artificial situation has shown this as a problem when it wouldn't cause any issues for real programs. I can't help thinking that there are some situations where you need a lot of memory for a short time though, and it would be nice to be able to use it briefly and then hand most of it back. Still, I see the practical difficulties with doing this. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
Steve Holden wrote: > Easy to say. How do you know the memory that's not in use is in a > contiguous block suitable for return to the operating system? I can > pretty much guarantee it won't be. CPython doesn't use a relocating > garbage collection scheme Fair point. That is difficult and I don't see a practical solution to it (besides substituting a relocating garbage collector, which seems like a major undertaking). > Right. So all we have to do is identify those portions of memory that > will never be read again and return them to the OS. That should be easy. > Not. Well, you have this nice int free list which points to all the bits which will never be read again (they might be written to, but if you're writing without reading then it doesn't really matter where you do it). The point about contiguous chunks still applies though. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
Steven D'Aprano wrote: > You've described an extremely artificial set of circumstances: you create > 40,000,000 distinct integers, then immediately destroy them. The obvious > solution to that "problem" of Python caching millions of integers you > don't need is not to create them in the first place. I know it's a very artificial setup - I was trying to make the situation simple to demonstrate in a few lines. The point was that it's not caching the values of those integers, as they can never be read again through the Python interface. It's just holding onto the space they occupy in case it's needed again. > So what's your actual problem that you are trying to solve? I have a program which reads a few thousand text files, converts each to a list (with readlines()), creates a short summary of the contents of each (a few floating point numbers) and stores this summary in a master list. From the amount of memory it's using, I think that the lists containing the contents of each file are kept in memory, even after there are no references to them. Also, if I tell it to discard the master list and re-read all the files, the memory use nearly doubles so I presume it's keeping the lot in memory. The program may run through several collections of files, but it only keeps a reference to the master list of the most recent collection it's looked at. Obviously, it's not ideal if all the old collections hang around too, taking up space and causing the machine to swap. >> but is there anything I can do to get that memory back without closing >> Python? > > Why do you want to manage memory yourself anyway? It seems like a > horrible, horrible waste to use a language designed to manage memory for > you, then insist on over-riding it's memory management. I agree. I don't want to manage it myself. I just want it to re-use memory or hand it back to the OS if it's got an awful lot that it's not using. Wouldn't you say it was wasteful if (say) an image editor kept an uncompressed copy of an image around in memory after the image had been closed? -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
[EMAIL PROTECTED] wrote: > Tom> ...and then I allocate a lot of memory in another process (eg. > open Tom> a load of files in the GIMP), then the computer swaps the > Python > Tom> process out to disk to free up the necessary space. Python's > Tom> memory use is still reported as 953 MB, even though nothing like > Tom> that amount of space is needed. From what you said above, the > Tom> problem is in the underlying C libraries, but is there anything I > Tom> can do to get that memory back without closing Python? > > Not really. I suspect the unused pages of your Python process are paged > out, but that Python has just what it needs to keep going. Yes, that's what's happening. > Memory contention would be a problem if your Python process wanted to keep > that memory active at the same time as you were running GIMP. True, but why does Python hang on to the memory at all? As I understand it, it's keeping a big lump of memory on the int free list in order to make future allocations of large numbers of integers faster. If that memory is about to be paged out, then surely future allocations of integers will be *slower*, as the system will have to: 1) page out something to make room for the new integers 2) page in the relevant chunk of the int free list 3) zero all of this memory and do any other formatting required by Python If Python freed (most of) the memory when it had finished with it, then all the system would have to do is: 1) page out something to make room for the new integers 2) zero all of this memory and do any other formatting required by Python Surely Python should free the memory if it's not been used for a certain amount of time (say a few seconds), as allocation times are not going to be the limiting factor if it's gone unused for that long. Alternatively, it could mark the memory as some sort of cache, so that if it needed to be paged out, it would instead be de-allocated (thus saving the time taken to page it back in again when it's next needed) > I think the process's resident size is more important here than virtual > memory size (as long as you don't exhaust swap space). True in theory, but the computer does tend to go rather sluggish when paging large amounts out to disk and back. Surely the use of virtual memory should be avoided where possible, as it is so slow? This is especially true when the contents of the blocks paged out to disk will never be read again. I've also tested similar situations on Python under Windows XP, and it shows the same behaviour, so I think this is a Python and/or GCC/libc issue, rather than an OS issue (assuming Python for linux and Python for windows are both compiled with GCC). -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
[EMAIL PROTECTED] wrote: > You haven't forgotten to do anything. Your attempts at freeing memory are > being thwarted (in part, at least) by Python's int free list. I believe > the int free list remains after the 10M individual ints' refcounts drop to > zero. The large storage for the list is grabbed in one gulp and thus > mmap()d I believe, so it is reclaimed by being munmap()d, hence the drop > from 320+MB to 250+MB. > > I haven't looked at the int free list or obmalloc implementations in > awhile, but if the free list does return any of its memory to the system > it probably just calls the free() library function. Whether or not the > system actually reclaims any memory from your process is dependent on the > details of themalloc/free implementation's details. That is, the behavior > is outside Python's control. Ah, thanks for explaining that. I'm a little wiser about memory allocation now, but am still having problems reclaiming memory from unused objects within Python. If I do the following: >>> (memory use: 15 MB) >>> a = range(int(4e7)) (memory use: 1256 MB) >>> a = None (memory use: 953 MB) ...and then I allocate a lot of memory in another process (eg. open a load of files in the GIMP), then the computer swaps the Python process out to disk to free up the necessary space. Python's memory use is still reported as 953 MB, even though nothing like that amount of space is needed. From what you said above, the problem is in the underlying C libraries, but is there anything I can do to get that memory back without closing Python? -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Garbage collection
Thinker wrote: > How do you know amount of memory used by Python? > ps ? top or something? $ ps up `pidof python2.5` USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND tew2426275 0.0 11.9 257592 243988 pts/6 S+ 13:10 0:00 python2.5 "VSZ" is "Virtual Memory Size" (ie. total memory used by the application) "RSS" is "Resident Set Size" (ie. non-swapped physical memory) -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: Technical Answer - Protecting code in python
flit wrote: > 1 - There is a way to make some program in python and protects it? I > am not talking about ultra hard-core protection, just a simple one > that will stop 90% script kiddies. Put it in an executable? It's more hidden than protected, but it will stop a fair few non-experts. I use and have been happy with pyinstaller, though there are other options. I use it more for ease of distribution to non-techy users, but it's also a simply way to hide your code. > 2 - If I put the code in web like a web service, how can I protect my > code from being ripped? There is a way to avoid someone using my site > and ripping the .py files? Configure your web-server properly and it will never serve up the .py files, only the results generated by them. I've not done it with Python, but I have set up a similar thing with Apache and XSLT where it will only give the generated data, not the code which created it. This is true even if there's an error in the code - it will just give "HTTP 500 Internal Server Error" and dump something a bit more useful to its error log. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Garbage collection
Hi all I suspect I may be missing something vital here, but Python's garbage collection doesn't seem to work as I expect it to. Here's a small test program which shows the problem on python 2.4 and 2.5: $ python2.5 Python 2.5 (release25-maint, Dec 9 2006, 15:33:01) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> (at this point, Python is using 15MB) >>> a = range(int(1e7)) >>> (at this point, Python is using 327MB) >>> a = None >>> (at this point, Python is using 251MB) >>> import gc >>> gc.collect() 0 >>> (at this point, Python is using 252MB) Is there something I've forgotten to do? Why is Python still using such a lot of memory? Thanks! -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: select windows
Dennis Lee Bieber wrote: > (And the Amiga could add even more complexity -- I still miss the > Amiga's ability to PUSH a window to the back while STILL KEEPING > FOCUS... Made it easy to type stuff into one window while reading data > from a covering window!) KDE's window manager can do this (and it is useful, you're right). I suspect most other window managers will offer it as an option, too. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out if another process is using a file
Jean-Paul Calderone wrote: > A better solution is to name or place files which are begin written in a > which is recognizable and only rename or move them to their final location > when they have been completely written. > > For example, name files ".new" as they are being written. When they are > fully written, drop the ".new" suffix. On the reader side, ignore any > file with a name ending in ".new". Yes, that would work very neatly but I don't have any control over the writing process. I think the modification time route might be the best option, but thanks to all for their replies. -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out if another process is using a file
js wrote: > How about using lock? > Let writing process locks the files before writing, and unlock after > the job's done. Is locking mandatory or co-operative? I don't have any control over the process which is doing the writing, so if it's co-operative it's no good to me. If it's mandatory, then I can try to acquire a lock on the file - if this fails or blocks, then the other process must have it open. Will this work? -- http://mail.python.org/mailman/listinfo/python-list
How to find out if another process is using a file
I'm writing a program which reads a series of data files as they are dumped into a directory by another process. At the moment, it gets sporadic bugs when it tries to read files which are only partially written. I'm looking for a function which will tell me if a file is opened in write-mode by another process - if it is, my program will ignore it for now and come back to it later. This needs to work on linux and windows. Mac OS would be a bonus too. An os-independent solution would be good, but I could write os-specific options and have it pick the appropriate one. Is there any way of doing this? I've drawn a blank with google so far. A nasty hack would be to use the file modification time, and wait until that's a few seconds in the past, but is there a nice solution? -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
Default event handlers in wxPython
Hi all I'm writing my first wxPython app and am having a problem with event handlers. I've set up a multi-part status bar and would like all the tooltips, menu help strings etc. to go into the second part of it. Is there some easy way of doing this? I've not found one, so have set up the following for the menu: self.Bind(wx.EVT_MENU_HIGHLIGHT, self.OnMenuHighlight) def OnMenuHighlight(self, event): self.SetStatusText(event.GetEventObject().GetHelpString(event.GetMenuId()), 1) ...this works fine. I've tried to set up the same for the toolbar: self.Bind(wx.EVT_TOOL_ENTER, self.OnToolbarHighlight) def OnToolbarHighlight(self, event): self.SetStatusText(event.GetEventObject().GetToolLongHelp(event.GetSelection()), 1) ...and this doesn't work. Well, it puts the text in the second part of the toolbar as requested, but the default handler is still being called and this messes up the first part of the toolbar which I want it to leave alone. How do I completely override the default handler for the toolbar? This method worked fine for menus and I'm a bit stuck. (ignore the indentation on the above examples - I know it's wrong, but long lines and usenet don't mix) -- I'm at CAMbridge, not SPAMbridge -- http://mail.python.org/mailman/listinfo/python-list
