Pygame - jerky motion
Hi- just installed pygame, not sure where to go for some help. I am on Fedora 3 running an ATI card but without the GL drivers installed. When I run any of the examples they work fine but they are very jerky. The animation is smooth for a few seconds and then the entire thing pauses for a heartbeat and then it goes on, pause, move, pause, move etc. Any ideas about what's up? (This is the same in fullscreen or running as a window) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pygame - jerky motion
donn wrote: > Hi- just installed pygame, not sure where to go for some help. > I am on Fedora 3 running an ATI card but without the GL drivers installed. > > When I run any of the examples they work fine but they are very jerky. > The animation is smooth for a few seconds and then the entire thing pauses > for a heartbeat and then it goes on, pause, move, pause, move etc. > Any ideas about what's up? > > (This is the same in fullscreen or running as a window) Well, I have since compiled and run some SDL demos (not Python, but c) and they also jerk and pause, so I'm guessing it's an SDL/Fedora/my card thing and not Pygame at all. F.I.Y I suppose :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Insane crazy question - printing commands
> import inspect > > class Box: > def draw(self): > print "hi" > return 3 > > x = Box() > print inspect.getsource(x.draw) Tried that, but get this error. I did a dir(inspect) in the command env. and getsource it definitely there... Traceback (most recent call last): File "inspect.py", line 1, in ? import inspect File "/home/donn/Projects/pythoning/fontyPython/extending/cairotests/containers/inspect.py", line 9, in ? print inspect.getsource(x.draw) AttributeError: 'module' object has no attribute 'getsource' /d -- http://mail.python.org/mailman/listinfo/python-list
Re: String formatting with %s
> dictionary-key/value syntax), you can do something like: > >>> number = lambda x: dict((str(i+1), v) for (i,v) in enumerate(x)) > >>> "%(2)s and %(1)s" % number(["A", "B"]) Whoa - that'll take me a little while to figure out, but it looks intriguing! Tah. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
Martin, I really appreciate your reply. I have been working in a vacuum on this and without any experience. I hope you don't mind if I ask you a bunch of questions. If I can get over some conceptual 'humps' then I'm sure I can produce a better app. > That's a bug in the app. It shouldn't assume that environment variables > are UTF-8. Instead, it should assume that they are in the locale's > encoding, and compute that encoding with locale.getpreferredencoding. I see what you are saying and agree, and I am confused about files and filenames. My app has to handle font files which can come from anywhere. If the locale (locale.getpreferredencoding) returns something like "ANSI" and I am doing an os.listdir() then I lose the plot a little... It seems to me that filenames are like snapshots of the locales where they originated. If there's a font file from India and I want to open it on my system in South Africa (and I have LANG=C) then it seems that it's impossible to do. If I access the filename it throws a unicodeDecodeError. If I use 'replace' or 'ignore' then I am mangling the filename and I won't be able to open it. The same goes for adding 'foreign' filenames to paths with any kind of string operation. My (admittedly uninformed) conception is that by forcing the app to always use utf8 I can access any filename in any encoding. The problem seems to be that I cannot know *what* encoding (and I get encode/decode mixed up still, very new to it all) that particular filename is in. Am I right? Wrong? Deluded? :) Please fill me in. > If you print non-ASCII strings to the terminal, and you can't be certain > that the terminal supports the encoding in the string, and you can't > reasonably deal with the exceptions, you should accept moji-bake, by > specifying the "replace" error handler when converting strings to the > terminal's encoding. I went through this exercise recently and had no joy. It seems the string I chose to use simply would not render - even under 'ignore' and 'replace'. It's really frustrating because I don't speak a non-ascii language and so can't know if I am testing real-world strings or crazy Tolkein strings. Another aspect of this is wxPython. My app requires the unicode build so that strings have some hope of displaying on the widgets. If I access a font file and fetch the family name - that can be encoded in any way, again unknown, and I want to fetch it as 'unicode' and pass it to the widgets and not worry about what's really going on. Given that, I thought I'd extend the 'utf8' only concept to the app in general. I am sure I am wrong, but I feel cornered at the moment. > > 3. I made the decision to check the locale and stop the app if the return > > from getlocale is (None,None). > I would avoid locale.getlocale. It's a pointless function (IMO). Could you say why? Here's my use of it: locale.setlocale( locale.LC_ALL, "" ) loc = locale.getlocale()[0] if loc == None: loc = locale.getlocale() if loc == (None, None): print localeHelp # not utf-8 (I think) raise SystemExit # Now gettext domain = "all" gettext.install( domain, localedir, unicode = True ) lang = gettext.translation(domain, localedir, languages = [loc] ) lang.install(unicode = True ) So, I am using getlocale to get a tuple/list (easy, no?) to pass to the gettext.install function. > Your program definitely, absolutely must work in the C locale. Of > course, you cannot have any non-ASCII characters in that locale, so > deal with it. This would mean cutting-out a percentage of the external font files that can be used by the app. Is there no modern standard regarding the LANG variable and locales these days? My locale -a reports a bunch of xx_XX.utf8 locales. Does it even make sense to use a non-utf8 locale anymore? > If you have solved that, chances are high that it will work in other > locales as well (but be sure to try Turkish, as that gives a > surprising meaning to "I".lower()). Oh boy, this gives me cold chills. I don't have the resources to start worrying about every single language's edge-cases. This is kind of why I was leaning towards a "use a utf8 locale please" approach. \d -- Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
Martin,
Thanks, food for thought indeed.
> On Unix, yes. On Windows, NTFS and VFAT represent file names as Unicode
> strings always, independent of locale. POSIX file names are byte
> strings, and there isn't any good support for recording what their
> encoding is.
I get my filenames from two sources:
1. A wxPython treeview control (unicode build)
2. os.listdir() with a unicode path passed to it
I have found that os.listdir() does not always return unicode objects when
passed a unicode path. Sometimes "byte strings" are returned in the list,
mixed-in with unicodes.
I will try the technique given
on:http://www.pyzine.com/Issue008/Section_Articles/article_Encodings.html#guessing-the-encoding
Perhaps that will help.
Re os.listdir():
> If you think you may have file names with mixed locales, and
> the current locale might not match the file name's locale, you should
> be using the byte string variant on Unix (which it seems you are already
> doing).
I gather you mean that I should get a unicode path, encode it to a byte string
and then pass that to os.listdir
Then, I suppose, I will have to decode each resulting byte string (via the
detect routines mentioned in the link above) back into unicode - passing
those I simply cannot interpret.
> Then, if the locale's encoding cannot decode the file names, you have
> several options
> a) don't try to interpret the file names as character strings, i.e.
>don't decode them. Not sure why you need the file names - if it's
>only to open the files, and never to present the file name to the
>user, not decoding them might be feasible
So, you reckon I should stick to byte-strings for the low-level file open
stuff? It's a little complicated by my using Python Imaging to access the
font files. It hands it all over to Freetype and really leaves my sphere of
savvy.
I'll do some testing with PIL and byte-string filenames. I wish my memory was
better, I'm pretty sure I've been down that road and all my results kept
pushing me to stick to unicode objects as far as possible.
> b) guess an encoding. For file names on Linux, UTF-8 is fairly common,
>so it might be a reasonable guess.
> c) accept lossy decoding, i.e. decode with some encoding, and use
>"replace" as the error handler. You'll have to preserve the original
>file names along with the decoded versions if you later also want to
>operate on the original file.
Okay, I'm getting your drift.
> That's not true. Try open("\xff","w"), then try interpreting the file
> name as UTF-8. Some byte strings are not meaningful UTF-8, hence that
> approach cannot work.
Okay.
> That's correct, and there is no solution (not in Python, not in any
> other programming language). You have to made trade-offs. For that,
> you need to analyze precisely what your requirements are.
I would say the requirements are:
1. To open font files from any source (locale.)
2. To display their filename on the gui and the console.
3. To fetch some text meta-info (family etc.) via PIL/Freetype and display
same.
4. To write the path and filename to text files.
5. To make soft links (path + filename) to another path.
So, there's a lot of unicode + unicode and os.path.join and so forth going on.
> > I went through this exercise recently and had no joy. It seems the string
> > I chose to use simply would not render - even under 'ignore' and
> > 'replace'.
> I don't understand what "would not render" means.
I meant it would not print the name, but constantly throws ascii related
errors.
I don't know if the character will survive this email, but the text I was
trying to display (under LANG=C) in a python script (not the immediate-mode
interpreter) was: "MÖgul". The second character is a capital O with an umlaut
(double-dots I think) above it. For some reason I could not get that to
display as "M?gul" or "Mgul".
BTW, I just made that up - it means nothing (to me). I hope it's not a swear
word in some other language :)
> As for font files - I don't know what encoding the family is in, but
> I would sure hope that the format specification of the font file format
> would also specify what the encoding for the family name is, or that
> there are at least established conventions.
You'd think. It turns out that font file are anything but simple. I am doing
my best to avoid being sucked-into the black hole of complexity they
represent. I must stick to what PIL/Freetype can do. The internals of
font-files are waay over my head.
> >> I would avoid locale.getlocale. It's a pointless function (IMO).
> As a consequence, it will return None if it doesn't know better.
> If all you want is the charset of the locale, use
> locale.getpreferredencoding().
Brilliant summary - thanks a lot for that.
> You could just leave out the languages parameter, and trust gettext
> to find some message catalog.
Right - I'll give that a go.
> > This would mean cutting-out a percentage of the external font files that
> > can be used by the a
Re: LANG, locale, unicode, setup.py and Debian packaging
Martin,
> Yes. It does so when it fails to decode the byte string according to the
> file system encoding (which, in turn, bases on the locale).
That's at least one way I can weed-out filenames that are going to give me
trouble; if Python itself can't figure out how to decode it, then I can also
fail with honour.
> > I will try the technique given
> > on:http://www.pyzine.com/Issue008/Section_Articles/article_Encodings.html
> >#guessing-the-encoding Perhaps that will help.
> I would advise against such a strategy. Instead, you should first
> understand what the encodings of the file names actually *are*, on
> a real system, and draw conclusions from that.
I don't follow you here. The encoding of file names *on* a real system are
(for Linux) byte strings of potentially *any* encoding. os.listdir() may even
fail to grok some of them. So, I will have a few elements in a list that are
not unicode, I can't ask the O/S for any help and therefore I should be able
to pass that byte string to a function as suggested in the article to at
least take one last stab at identifying it.
Or is that a waste of time because os.listdir() has already tried something
similar (and prob. better)?
> I notice that this doesn't include "to allow the user to enter file
> names", so it seems there is no input of file names, only output.
I forgot to mention the command-line interface... I actually had trouble with
that too. The user can start the app like this:
fontypython /some/folder/
or
fontypython SomeFileName
And that introduces input in some kind of encoding. I hope that
locale.getprefferedencoding() will be the right one to handle that.
Is such input (passed-in via sys.argv) in byte-strings or unicode? I can find
out with type() I guess.
As to the rest, no, there's no other keyboard input for filenames. There *is*
a 'filter' which is used as a regex to filter 'bold', 'italic' or whatever. I
fully expect that to give me a hard time too.
> Then I suggest this technique of keeping bytestring/unicode string
> pairs. Use the Unicode string for display, and the byte string for
> accessing the disc.
Thanks, that's a good idea - I think I'll implement a dictionary to keep both
and work things that way.
> I see no problem with that:
> >>> u"M\xd6gul".encode("ascii","ignore")
> 'Mgul'
> >>> u"M\xd6gul".encode("ascii","replace")
> 'M?gul'
Well, that was what I expected to see too. I must have been doing something
stupid.
\d
--
http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> So on *your* system, today: what encoding are the filenames encoded in? > We are not talking about arbitrary files, right, but about font files? > What *actual* file names do these font files have? > > On my system, all font files have ASCII-only file names, even if they > are for non-ASCII characters. I guess I'm confused by that. I can ls them, so they appear and thus have characters displayed. I can open and cat them and thus the O/S can access them, but I don't know whether their characters are strictly in ascii-limits or drawn from a larger set like unicode. I mean, I have seen Japanese characters in filenames on my system, and that can't be ascii. You see, I have a large collection of fonts going back over 10 years and they came from usenet years ago and so have filenames mangled all to hell. I can't always *type* some of their names and have to use copy/paste to, for example, ls one of them. Again, it's working from ignorance (my own) : I assume filenames in different countries will be in character sets that I have never (nor will I ever) see. But I have to cover them somehow. > > Or is that a waste of time because os.listdir() has already tried > > something similar (and prob. better)? > "better" is a difficult notion here. Is it better to produce some > result, possibly incorrect, or is it better to give up? I think I see, combined with your previous advice - I will keep byte strings alongside unicode and where I can't get to the unicode for that string, I will keep an 'ignore' or 'replace' unicode, but I will still have the byte string and will access the file with that anyway. > If the user has set up his machine correctly: yes. Meaning, I am led to assume, the LANG variable primarily? \d -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> If you can all ls them, and if the file names come out right, then > they'll have the same encoding. Could it not be that the app doing the output (say konsole) could be displaying a filename as best as it can (doing the ignore/replace) trick and using whatever fonts it can reach) and this would disguise the situation? I don't think one can call any string a plain ascii string anymore. I have been looking for somewhere online that I can download files obviously in a non-ascii set (like japan someplace) but can't find anything easy. I want to see exactly how my system (Kubuntu 7.10) handles things. > I never heard before that font files use non-ASCII file names, They are files, named as any other file - those that are created by people get called whatever they want, under whatever locale they used. Still, I don't fully understand how this is all handled. > don't see the point in doing so - isn't there typically a font name > *inside* the font file as well, so that you'd rather use that for > display than the file name? Yes, but sometimes I can't reach that - segfaults and so forth. I also need to write the filename to a text file for logging. > Of course, *other* files (text files, images etc) will often use > non-ASCII file names. Same as font files - I am talking mainly about TTF files here. Mainly Arrr, pass the rum, matey fonts ;) (Which I don't use in designs, but have kept over the years.) > However, they won't normally have mixed > encodings - most user-created files on a single system should typically > have the same encoding (there are exceptions possible, of course). Well, if I am collecting fonts from all over the place then I get a mixed-bag. > > Meaning, I am led to assume, the LANG variable primarily? > Yes. Thanks. Good to know I'm on the right track. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> No. It may use replacement characters (i.e. a question mark, or an empty > square box), but if you don't see such characters, then the terminal has > successfully decoded the file names. Whether it also correctly decoded > them is something for you to check (i.e. do they look right?) Okay. So, the picture I get is: *If* my locale *happens* to be the right one then the filename will appear properly. If it does not cover that file, then that filename will appear with ? marks in the name. Because I use en_ZA.utf8 it's doing a very good job of decoding a wide variety of filenames and therefore I rarely see ? characters. What happens if there is a filename that cannot be represented in it's entirety? i.e. every character is 'replaced'. Does it simply vanish, or does it appear as "?" ? :) I spent an hour trying to find a single file on the web that did *not* have (what seemed like) ascii characters in it and failed. Even urls on Japanese websites use western characters ( a tcp/ip issue I suspect). I was hoping to find a filename in Kanji (?) ending in .jpg or something so that I could download it and see what my system (and Python) made of it. Thanks again, \d -- "Life results from the non-random survival of randomly varying replicators." -- Richard Dawkins Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
Martin, I want to thank you for your patience, you have been sterling. I have an overview this evening that I did not have this morning. I have started fixing my code and the repairs may not be that extreme after all. I'll hack-on and get it done. I *might* bug you again, but I'll resist at all costs :) Much appreciated. \d -- "A computer without Windows is like chocolate cake without mustard." -- Anonymous Coward /. Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
Well, that didn't take me long... Can you help with this situation? I have a file named "MÖgul.pog" in this directory: /home/donn/.fontypython/ I set my LANG=C Now, I want to open that file from Python, and I create a path with os.path.join() and an os.listdir() which results in this byte string: paf = ['/home/donn/.fontypython/M\xc3\x96gul.pog'] I *think* that the situation is impossible because the system cannot resolve the correct filename (due the locale being ANSI and the filename being other) but I am not 100% sure. So, I have been trying combinations of open: 1. f = codecs.open( paf, "r", "utf8" ) I had hopes for this one. 2. f = codecs.open( paf, "r", locale.getpreferredencoding()) 3. f = open( paf, "r") But none will open it - all get a UnicodeDecodeError. This aligns with my suspicions, but I wanted to bounce it off you to be sure. It does not really mesh with our previous words about opening all files as bytestrings, and admits failure to open this file. Also, this codecs.open(filename, "r", ) function: 1. Does it imply that the filename will be opened (with the name as it's type : i.e. bytestring or unicode ) and written *into* as 2. Imply that filename will be encoded via and written into as It's fuzzy, how is the filename handled? \d -- He has Van Gogh's ear for music. -- Billy Wilder Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> Now you are mixing two important concepts - the *contents* > of the file with the *name* of the file. Then I suspect the error may be due to the contents having been written in utf8 from previous runs. Phew! It's bedtime on my end, so I'll try it again when I get a chance during the week. Thanks muchly. \d -- snappy repartee: What you'd say if you had another chance. Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> Can you please type > paf = ['/home/donn/.fontypython/M\xc3\x96gul.pog'] > f = open(paf, "r") I think I was getting a ghost error from another try somewhere higher up. You are correct, this does open the file - no matter what the locale is. I have decided to keep the test for a decode error because files created under different locales should not be written-to under the current one. I don't know if one can mix encodings in a single text file, but I don't have time to find out. It is getting messy with my test files created in differing locales, and my code changing so quickly. > See above. The encoding in codecs.open has no effect at all on > the file name; it only talks about the file content. Thanks, I suspected as much but it's a subtle thing. Best, \d -- "It is almost as if the human brain were specifically designed to misunderstand Darwinism, and to find it hard to believe.." -- Richard Dawkins Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
Given that getlocale() is not to be used, what's the best way to get the locale later in the app? I need that two-letter code that's hidden in a typical locale like en_ZA.utf8 -- I want that 'en' part. BTW - things are hanging-together much better now, thanks to your info. I have it running in locale 'C' as well as my other test locales. What a relief! \d -- http://mail.python.org/mailman/listinfo/python-list
Re: LANG, locale, unicode, setup.py and Debian packaging
> You get the full locale name with locale.setlocale(category) (i.e. > without the second argument) Ah. Can one call it after the full call has been done: locale.setlocale(locale.LC_ALL,'') locale.setlocale(locale.LC_ALL) Without any issues? > > I need that two-letter code that's hidden in a > > typical locale like en_ZA.utf8 -- I want that 'en' part. Okay, I need it because I have a tree of dirs: en, it, fr and so on for the help files -- it's to help build a path to the right html file for the language being supported. > Not sure why you want that. Notice that the locale name is fairly system > specific, in particular on non-POSIX systems. It may be > "English_SouthAfrica" on some systems. Wow, another thing I had no idea about. So far all I've seen are the xx_yy.utf8 shaped ones. I will have some trouble then, with the help system. Thanks, \d -- "There may be fairies at the bottom of the garden. There is no evidence for it, but you can't prove that there aren't any, so shouldn't we be agnostic with respect to fairies?" -- Richard Dawkins Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: piping into a python script
> wget -i - > it doesn't do anything, just waits for your input. Your applications > probably should behave the same. Okay, that works for me. > Paddy wrote: > > ls *.a | ./fui.py -f - *.b > It doesn't seem to me that -f parameter is necessary for your > application. Yes and no, I have another option that needs to take a variable number of args. > It should treat all the arguments as the filenames, > shouldn't it? And when one of the filenames is -, just try to read > stdin. I have tested getopt and it strips the lone '-' out. I can get it from sys.argv, but then I am really doing more parsing than I want to. It's a tricky job this. I think I will look in sys.argv, if I find a single dash the I will replace that element in the list with whatever comes from stdin. Then I'll pass all of it to getopt. Thanks for the help. \d -- When you allow legends to rule your life, your world is based on fiction -- Segio Aragones (Groo the Wanderer Number 99) Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: piping into a python script
Thanks for the tips, I'll decode and try 'em all out. > Ah yes, Groo. Ever wonder who would win if Groo and Forrest Gump fought > each other? Heh ;) I reckon they'd both die laughing. Be fun to watch -- if anyone else survived! \d -- "A computer without Windows is like chocolate cake without mustard." -- Anonymous Coward /. Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: piping into a python script
Andrew, Thanks for your tips. I managed to get a working script going. I am sure there will be stdin 'issues' to come, but I hope not. If anyone wants to have a look, it's on the cheese shop at: http://pypi.python.org/pypi/fui \d -- "You know, I've gone to a lot of psychics, and they've told me a lot of different things, but not one of them has ever told me 'You are an undercover policewoman here to arrest me.'" -- New York City undercover policewoman Fonty Python and other dev news at: http://otherwiseingle.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
pyZui - anyone know about this?
Hi, I happened upon this youtube link: http://www.youtube.com/watch?v=57nWm984wdY It fairly blew my socks off. In it a fellow by the name of David Roberts demos a zui written in Python. Aside from the zooming (which is impressive enough) it show embedding of images, pdf files, web pages and text. He says nothing about what toolkits were used or how it might have been done. It's Linux-based, but no other info. On some googling, I can only find a few bug reports on pypi related to pyQt. I would really like to find out how that ZUI was done, it's simply amazing. Any clues out there? \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Friday 11 December 2009 12:38:46 Daniel Fetchinson wrote: > Youtube has a link 'Send message' on the profile of users, maybe > sending a message to the person who uploaded the video will give you a > useful response. > I'm a Tube-tard so that never crossed my mind. Will give it a go. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Monday 14 December 2009 00:10:52 David Boddie wrote: > Doesn't the author give his e-mail address at the end of the video? > (Maybe I'm thinking of a different video.) > Yes, in a quick and garbled way :) I have yet to try to contact the author or the youtube poster -- been too busy. I was hoping someone on the list may recognize what tools he was using, or have some insight into how they would attack the problem. I have pondered it from a wxPython pov, that being all I am experienced with and I would have no chance of recreating that demo. Is it using some kind of built-in QT/KDE voodoo? \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Tuesday 15 December 2009 01:43:52 David Boddie wrote: > I managed to catch his address and sent him a message saying that people > were discussing PyZUI in this thread. > Oooh. Sits,fidgets and waits. I want my socks back! (OP) :D \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Tuesday 15 December 2009 04:29:39 David Roberts wrote: > Yes, the toolkit used is PyQt. \me makes note to start learning PyQt asap. > and employs pyramidal tiling for efficiency \me ... time to hit Wikipedia :) > (I haven't used any Qt/KDE voodoo in this regard). Imho, your code should *become* that voodoo -- from what I saw in that vid it's unique and has such promise. > QtWebKit, and PDF with the pdftoppm utility. Ah, thanks. > The project is opensource (GPLv2), but just hasn't been published > yet :) . I'll try to make a release over the next few days, and I'll > post a link here when I do. Can't wait. David, thanks for replying here on the list. Well done on your pyZui and I hope it catches fire in people's imaginations. I think that fire may explain why my socks are missing! :D \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Tuesday 15 December 2009 11:12:21 Martijn Arts wrote: > You could do some really awesome stuff with that! I love the webpage > example where you zoom in on the exclamation mark and there's a new page. > It is very cool, but I would inject a note of caution here: I'd a hate a zui to become a case of "hunt-the-zoom." A link is a link. They already work very well, click and it goes to the page. I find the notion of minute "hot" areas to be a little obscure -- Quick! Zoom into the last full-stop, it's a whole word in there! What I would enjoy is when you click a link - it zooms into the sub-page so you get a feeling of traversal. Back buttons would zoom out again. Add to that a kind of birds'-eye view of one's history (like a thumbnails node-graph of some kind) and it would be perfect! \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Wednesday 16 December 2009 09:42:14 David Roberts wrote: > PyZUI 0.1 has been released: Magic! Grabbed a tarball yesterday. \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Wednesday 16 December 2009 07:03:19 David Roberts wrote: > It involves scaling an image to various resolutions, and partitioning > them into fixed-size tiles. It's roughly the same technique used by > Google Maps/Earth. Thanks. That gives me something to go on. Wikipedia didn't like my search terms. > > ZUIs are useful for particular types of data - images & mapping > > especially - but I'd hate to have to navigate my desktop using its > > approach. Ever since Corel Draw in the 90's zoomed into my life I have been in love with the idea of an endless canvas that makes me feel like a satellite on a bungee cord. I think it would fit the desktop very well. Personally I see a merging of normal app windows and a zui: some kind of new window manager. If I planned it out it would look something like this: Your apps all run as they do now*, but they live on this endless plain. Perhaps it can be divided up into 'zones' or 'galaxies' or something. I would have a 'hyperspace' or 'hyperlink' or 'jump' facility (like alt-tab, I guess) to make transits from one custom-defined area to another quick. I would have a home position for the view -- like Inkscape does in terms of show all, zoom to selected, zoom to last, etc. I would have rules about traversing. Things like file-managers need some kind of static display - like the bread crumbs and up, back, home etc. Each app would only be active when 'locked-in', beyond that it's a bitmap of the last paint. You could drag apps around when you zoom out, and you can resize them at any time too. (Just imagine OOCalc in a zui! Super/Capslock and mouse wheel for scroll/pan) The other cool idea I had was to (handwavium here) graphically convey the notion of pipes and import/export between apps. Also between any nodes across the Universe of the zui. Perhaps a special 'node view' that overlays and shows all the conduits between them -- sharp where your mouse is, faded away from that so the whole thing is not too complex. Imagine the flow from Inkscape to Gimp and back. Instead of File -> Export and then File -> Import, you connect pipes along the side of each app. Inkscape, [save selected as png (properties preset)] goes to Gimp [import to layers by names (a script perhaps)] Now as you work in Inkscape and hit a hotkey, all your selected vectors are sent to Gimp which reacts as if you were there and places the new pngs into layers. This can work both ways and between multiple programs. Mix-in Blender and Scribus and Lyx and some grep and a loop or two and some imagemagick... Ah, I better stop. I can ramble on sometimes :) *I have many issues with the endless variety of re-invented wheels afa gui toolkits go. This is another whole can of shai-Hulud... I wrote some stuff about this a while back, if anyone wants to be put to sleep: http://otherwise.relics.co.za/wiki/Particles/DreamDesignApp/ :) \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Thursday 17 December 2009 10:54:59 David Roberts wrote: > Have you seen Eagle Mode[1]? > Yes. It's a strange beast. Good start I think; but addicted to zooming, to the detriment of the managing aspects I think. Still, here I sit writing no code and pontificating! \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyZui - anyone know about this?
On Thursday 17 December 2009 19:46:41 Terry Reedy wrote: > His idea was for a document rather than > app centric plain. These days I find the notion of monolithic apps to be a pita. The concept of many small black boxes (but open source) that each do a single job and pipe in/out is so much more powerful. I don't see why everything in a gui and down can't be such a box. Then we get to wire them together as needed. We'd still have 'big apps' but they would be constructed more loosely and we could adapt them to fit real life needs. I dunno. I think big apps are dinosaurs. As much as I love Inkscape and Blender and others, they are all islands with vast gulfs between them. And let's have Python glue them all together! > Not clear how one would pipe data from app to app in > his model, though. The picture I have of it is illustrated by Blender's material node system. have a look at this pic: http://upload.wikimedia.org/wikipedia/commons/2/26/Working_with_Nodes_Blender.PNG Just a mental jump-off point. Think bash meets zui with a Python driving. :D \d -- \/\/ave: donn.in...@googlewave.com home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Significant whitespace
On Saturday 02 January 2010 00:02:36 Dan Stromberg wrote: > I put together a page about significant whitespace (and the lack thereof). The only thing about Python's style that worries me is that it can't be compressed like javascript can*, and perhaps that will prevent it becoming a browser-side language one day. How I'd love to code PyQuery instead of JQuery! * Or am I wrong? \d -- http://mail.python.org/mailman/listinfo/python-list
Re: SVG PIL decoder
On Wednesday 30 September 2009 18:01:50 Patrick Sabin wrote: > I would like to open svg files with PIL, but svg doesn't seem to be > supported. Does anyone know about a svg decoder for the PIL? Have a look at Cairo (python-cairo) in conjunction with librsvg (python-rsvg) -- that'll fix you up. You can go from an SVG to a PNG/array and thence into PIL if you need to. \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: SVG PIL decoder
On Thursday 01 October 2009 01:08:28 Patrick Sabin wrote: > Thanks for the tip. Got it work, although it was a bit tricky, as > resizing doesn't seem to be supported by python-rsvg and > cairo.ImageSurface.create_from_png doesn't allow StringIO or My best suggestions are to visit the Cairo website -- inside there somewhere is a recipe page with many samples in Python. Next would be http://www.tortall.net/mu/wiki/CairoTutorial. Third is a tutorial I made (perhaps less useful) on my site http://otherwise.relics.co.za/wiki/Tuts/Python/Cairo/ links at bottom of that page Fourth is to join the ca...@cairographics.org mailing list at http://lists.cairographics.org/mailman/listinfo/cairo they are super helpful. Lastly is my animation API (in sig)which is also Python and may help you with the source. The general idea for scaling is to use matrices (cairo provides all commands) and then output the surface to a file-like object. My animation API brings selected snippets of SVG in from an Inkscape file (tagged by id), animates them by tweening and can output each frame to another SVG or to a PNG. HTH, \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: organizing your scripts, with plenty of re-use
Great description - wish the Python docs could be as clear. Thanks. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Skeletal animation
On Monday 05 October 2009 18:09:46 Manowar wrote: > just need to know if i can manipulate the bones in > realtime with python. If you are looking for some kind of "from awesome import Bones", then I really don't know of anything. You should look at the various 3D toolkits (like Panda 3D, python-gl etc.) and use what they offer and extend it. see: http://www.panda3d.org/wiki/index.php/Attaching_an_Object_to_a_Joint \d -- http://mail.python.org/mailman/listinfo/python-list
Re: What do I do now?
On Monday 12 October 2009 00:53:42 Someone Something wrote: > 1) What should I start programming (project that takes 1-2 months, not very > short term)? > 2) Whtat are some good open source projects I can start coding for? These kinds of questions amaze me. Surely you are a kid in a candy shop when it comes to things to code? The best place to start a project is to scratch an itch: pick something that really bugs you, or something that is plain missing, or something that you are interested in, and start solving the problem. No O/S or Desktop or App is perfect. There are a thousand gaps between all those things that need solutions or improvements. Find an "itch" and either: 1. Find a project in that direction and try to join. 2. Start your own. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Unexpected exit of Python script
On Wednesday 14 October 2009 14:23:11 vicky wrote: > I just want to know that, due to any reason if a script exits, is > their some way to release all the resources acquired by the script > during execution ? Python cleans-up after itself so I would not worry about that until you are an expert and need to split hairs. Just get on with learning and writing code. Look at exceptions (try, except) for this kind of thing -- but it's a basic part of learning Python anyway. About the only thing I ever found I could not catch was a segfault (under Linux) and to get around that I open my main app from a smaller one using the subprocess module. When the main app crashes (which it does sometime) that process dies suddenly, but it falls-back to the original script which then detects the error return code and can continue whatever it needs to do. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: how to write a unicode string to a file ?
On Friday 16 October 2009 01:59:43 Stephen Hansen wrote: > Just to say, thanks for that post. I am an old ascii dog and this notion of encoding and decoding is taking such a lng time to penetrate my thick skull. Little snippets like your post are valuable insights. I have made a gnote of it! \d -- http://mail.python.org/mailman/listinfo/python-list
Re: how to write a unicode string to a file ?
On Friday 16 October 2009 13:08:38 Niklas Norrthon wrote: > that made me think I understand > Lol, I know the feeling! :D I have read that page a few times, and I always emerge thinking 'now I've got it'. Then a week passes... \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is python so sad?
> > def ...(...(: > > ... > > class ...(...(: > I disagree. It looks like one smiley is drooling into the other smiley's > mouth. Two smileys, one function? Yuk! That *def*initely has no *class* ... :P \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Python & Go
On Saturday 14 November 2009 22:23:40 Paul Rubin wrote: > they'll have to call it Go2 Lol. Or we could fork it and call it Gosub ... and never return! \d -- http://mail.python.org/mailman/listinfo/python-list
pyclutter anyone?
Hi, this is a little bit of a cross-post. I posted to the clutter list, but there's little activity there. I am trying to make sense of pyClutter 1.0. Could anyone point me to an example (or post one) that shows clipping from a path applied to child objects? For example: A star shape that contains a bunch of moving rectangles which will travel/size/rotate with the star, but are clipped to the shape of the star. I suspect this will involve a custom clutter.Group class of some kind, with cogl paths and an on_paint() method, but I can find no headway on the web so far. Hope someone can help! \d -- Fonty Python and Things! -- http://otherwise.relics.co.za/wiki/Software -- http://mail.python.org/mailman/listinfo/python-list
Re: pyclutter anyone?
No one uses pyClutter?
I have some code, it does not work, but maybe this will start to help
solve the problem:
import clutter
from clutter import cogl
x,y=0,0
def boo(tl,frame,obj):#,evt):
global x,y
obj.set_position(x, y)
def xy(obj,evt):
global x,y
x,y = evt.x,evt.y
class G(clutter.Group):
"""
Attempt to make a Group that can clip its children to a path.
"""
def __init__(self,*args):
clutter.Group.__init__(self,*args)
#self.set_clip(0,0,10,10)
self.connect("paint",self.do_paint)
self._color = clutter.Color(255,200,100)
def do_paint(self, args):
width,height=200,200
cogl.path_move_to(width / 2, 0)
cogl.path_line_to(width, height)
cogl.path_line_to(0, height)
cogl.path_line_to(width / 2, 0)
cogl.path_close()
#cogl.set_source_color(self._color)
#cogl.path_fill()
## Colour me lost from here...
cogl.clip_push_from_path()
clutter.Group.do_paint(self)
cogl.clip_pop()
def main():
global group1
stage = clutter.Stage()
stage.set_size(500, 500)
stage.set_color(clutter.color_from_string("#FFF"))
rect1, rect2, rect3 = clutter.Rectangle(), clutter.Rectangle(),
clutter.Rectangle()
group1, group2, group3 = G(), clutter.Group(), clutter.Group()
group1.add(rect1, group2)
group2.add(rect2, group3)
group3.add(rect3)
group1.set_position(100, 100)
group2.set_position(100, 100)
group3.set_position(100, 100)
rect1.set_position(0, 0)
rect2.set_position(0, 0)
rect3.set_position(0, 0)
rect1.set_size(150, 150)
rect2.set_size(150, 150)
rect3.set_size(150, 150)
rect1.set_color(clutter.color_from_string("#FF90"))
rect2.set_color(clutter.color_from_string("#00FF0090"))
rect3.set_color(clutter.color_from_string("#FF90"))
stage.add(group1)
stage.show_all()
group1.show_all()
group2.show_all()
group3.show_all()
stage.connect("key-press-event", clutter.main_quit)
stage.connect('destroy', clutter.main_quit)
stage.connect('motion-event', xy)
path = clutter.Path('M 0 0 L 300 0 L 300 300 L 0 300z')
timeline = clutter.Timeline(4000)
timeline.set_loop(True)
alpha = clutter.Alpha(timeline,clutter.EASE_OUT_SINE)
p_behaviour = clutter.BehaviourPath(alpha, path)
path.add_move_to(0, 0)
p_behaviour.apply(group3)
timeline.add_marker_at_time("foo",2000)
timeline.start()
t=clutter.Timeline(1000)
t.set_loop(True)
t.connect('new-frame', boo, group1)
t.start()
clutter.main()
if __name__ == '__main__':
main()
\d
--
Fonty Python and Things! -- http://otherwise.relics.co.za/wiki/Software
--
http://mail.python.org/mailman/listinfo/python-list
Re: Creating formatted output using picture strings
On 10/02/2010 20:36, pyt...@bdurham.com wrote: def picture(s, pic, placeholder='@'): nextchar=iter(s).next return ''.join(nextchar() if i == placeholder else i for i in pic) Hell's teeth - even I understood that! Amazing solution. \d -- Fonty Python and Things! -- http://otherwise.relics.co.za/wiki/Software -- http://mail.python.org/mailman/listinfo/python-list
Re: How to keep effects of image filters going for some seconds?
On 21/03/2010 09:23, Ren Wenshan wrote: I have been learning Panda3D, an open source 3D engine, Ask on the Panda3D forums, you will get good help there. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Hello [How to run your code]
On 10/07/2010 13:05, Dani Valverde wrote: It could be a solution. But I am used to work with gEdit using the R statistical programming language plugin, and I am able to send the code to console instead of typing it in. To run your code, save it to a file 'mycode.py' (or whatever), then open a console and cd into that directory, then: python mycode.py That will get you started. Keep the console open and alt-tab to it whenever you want to run your code. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
On 02/08/2010 17:35, Mark Lawrence wrote: aka the colon. :) Ha. This is a case of the colon being the appendix! \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to set a cookie within a python script
On 04/08/2010 20:09, Dotan Cohen wrote: Don't forget that the Euro symbol is outside the Greek character set. I could make some kind of economic joke here, but I'm also broke :D \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't I run this test class?
On Friday 11 September 2009 09:30:42 Kermit Mei wrote: Do this: class Test(object): > t1 = Test And this: t1 = Test() That makes an instance and runs the __init__ \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
ImageFont family mojibake
Python 2.6
PIL Version: 1.1.6-3ubuntu1
libfreetype6 Version: 2.3.9-4ubuntu0.1
Hello,
I have a feeling I've asked this in the distant past, but it's recently
emerged as a bug in my app so can anyone point me in the right direction?
In Fonty Python, when I draw the family name of a font some* are mojibaked (is
that a word?) in the form: s??? etc. The string is drawn to a DC with
wxPython, but is fetched from the font via ImageFont, like so:
f=ImageFont.truetype("FGTshgyo.TTF",1,encoding="utf-8")
print f.font.family
'?s'
So, the string is plain (not unicode) and wrong from the get-go.
*"some" being those fonts that contain family names not in western encodings.
The sample font that demonstrates the problem and was sent to me to test is
called: BGPENKB.TTF another is FGTshgyo.TTF
These are substantial files and I can't attach them to a list. if you need them
for testing I can send them to another email address, or upload them
somewhere.
I have been oft helped in the past on matters unicode, but this does not mean
I have grokked. (Alas my formative years were all spend in the fantasy of 8bit
ascii :) )
I hope there's some simple encoding="voodoo" that might fix this. The problem
is, I guess, knowing *what* that voodoo is for arbitrary fonts (which can come
from any source).
Any assistance would not go amiss.
\d
--
home: http://otherwise.relics.co.za/
2D vector animation : https://savannah.nongnu.org/projects/things/
Font manager : https://savannah.nongnu.org/projects/fontypython/
--
http://mail.python.org/mailman/listinfo/python-list
Re: ImageFont family mojibake
On Saturday 12 September 2009 07:55:14 Lie Ryan wrote:
> > f=ImageFont.truetype("FGTshgyo.TTF",1,encoding="utf-8")
> > print f.font.family
> > '?s'
> Are you sure that your terminal (Command Prompt/bash/IDLE/etc) supports
> utf-8 and that it is properly set up to display utf-8?
Fairly sure... It's konsole under Kubuntu Jaunty. My locale it utf-8. To tell
the truth I am not sure how to be sure.
OTOH - when I pass that family name string to wxPython (unicode version) to be
drawn to a DC it displays the exact same string that I see in Python's
console. So even if my console is misconfigured, the string is still looking
flawed.
> Try:
> print repr(f.font.family)
Same result. Also same for print unicode(...)
I wonder about the return result from f.font.family. If it was a unicode
object should I not see u"s???" which would show that my terminal can't
draw the glyphs, but it knows it's a unicode?
print type(f.font.family)
Hmmm. This seems wrong.But I could be making a mistake.
> > I hope there's some simple encoding="voodoo" that might fix this. The
> > problem is, I guess, knowing *what* that voodoo is for arbitrary fonts
> > (which can come from any source).
> If all else fails, you can simply compare the byte string representation
> of the font family name.
I don't follow this. What would I compare it to?
Thanks for helping.
\d
--
home: http://otherwise.relics.co.za/
2D vector animation : https://savannah.nongnu.org/projects/things/
Font manager : https://savannah.nongnu.org/projects/fontypython/
--
http://mail.python.org/mailman/listinfo/python-list
Re: ImageFont family mojibake
On Saturday 12 September 2009 17:30:19 garabik- news-2005...@kassiopeia.juls.savba.sk wrote: > apt-get install unicode > unicode 0100.. Nice tip, thanks. > if you see a lot of accented letters (and not squares or question marks), > you can be sure I see the accented chars -- so now I am more certain that the problem is in the font.family function. Something deep in the C code... \d -- http://mail.python.org/mailman/listinfo/python-list
Re: How to print without spaces?
print "a"+"b" \d -- http://mail.python.org/mailman/listinfo/python-list
Re: easy question, how to double a variable
On Monday 21 September 2009 22:49:50 daggerdvm wrote: > you brain needs error checking! try: return response() except Troll,e: raise dontFeed(anymore=True) \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting return code for a Python script invoked from a Linux shell script
On Wednesday 23 September 2009 18:51:29 volcano wrote: > exit_code = !$ I think it's $? to get the code. \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: arrays in python
On Wednesday 23 September 2009 19:14:20 Rudolf wrote: > I want to allocate an array and then populate it > using a for loop. You don't need to allocate anything, just use the list or dictionary types. l=[] #empty list for x in range(1,500): l.append(x) \d -- http://mail.python.org/mailman/listinfo/python-list
Re: arrays in python
On Wednesday 23 September 2009 22:12:24 Ethan Furman wrote: > Works great if you want 4,999,999 elements. ;-) Omit the '1' if you > want all five million. Yes. Fenceposts always get me :) And I was just reminded that one can: l=range(500) \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: how to truncate to get the 1st 5 chars from a string
On Thursday 24 September 2009 05:05:45 MacRules wrote: > s="1234abcd" print s[0:4] should do it. Not sure it's a function though. \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributing Python-programs to Ubuntu users
On Friday 25 September 2009 08:15:18 Olof Bjarnason wrote: > Does anyone have any hint on a more economic way of creating > single-file distribution packages You could use distutils (setup.py) and include a readme that explains what apt-get commands to use to install pygame, etc. Generally it's better to *not* include the kitchen-sink with your apps; rather expect the user to have those libraries already or be able to fetch them with ease. I did my best at explaining that deeply confusing setup.py process here: http://wiki.python.org/moin/Distutils/Tutorial I have also seen two other approaches: 1. A new app called 'Quickly' which is some kind of magical auto-do- everything-ubuntu connected to Launchpad. From what I hear it sounds very cool. https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/Quickly 2. The Ubuntu PPA repositories -- google around. (Seems Quickly does this too) hth, \d -- home: http://otherwise.relics.co.za/ 2D vector animation : https://savannah.nongnu.org/projects/things/ Font manager : https://savannah.nongnu.org/projects/fontypython/ -- http://mail.python.org/mailman/listinfo/python-list
Walking deeply nested lists
This is all about walking trees, recursion and generators. None of which fit my brain at all! From an XML tree (an SVG file) I build a bunch of Tag objects. [I use lxml, but I am combining multiple svg files into a 'forest' of trees, so I can't use the lxml walking methods because they all stop at the 'end' of a branch where there is actually a 'link' over to another tree.] Each Tag has a flatwalk() method. The return from that is a list which can be deeply nested. As an example, something like this: L=[1, [2, 3, [4, [5, 6], 7], 8], [9, 10] ] (The numbers in the example would actually be Tag Instances.) Aim 1 --- I'm trying to write a generator around such lists so that I can 'walk' them: for parent, child in mystery_generator(L): print level, item Right now, I am running a 'flatten' function on the entire list (which I don't savvy, I found it online) and then I iterate over that flattened list. This doesn't feel right to me. (Code at end.) Aim 2 --- The Objects that represent the svg tags use that flatwalk() method to build the nested list, I'd far prefer flatwalk() to be directly useable in something like this way: for container, child in some_tag.flatwalk(): print container, child The flatwalk() function is (and this is another puzzle see *) kind of recursive. "For each of my children, tell that child to go flatwalk()". (Code at end.) I am not sure how to turn such a thing into a generator. I keep wondering how os.walk() does its thing. My hierarchy of Tag objects can be thought of as directories (tags:g, symbol, svg), files (path, circle, etc.) and soft-links (use tags). * If an Instance calls a method on *another* Instance of the *same* class, is this still recursion? And how does this 'stack up'? I mean, literally, on the stack. Does each instance get its own stack, or does all the push, call, pop stuff happen in one main stack? (I worry about recursion depth limits because svg trees can get quite deep.) The walking code so far: ## Found code. def flatten(input): output = [] stack = [] stack.extend(reversed(input)) while stack: top = stack.pop() if isinstance(top, list): stack.extend(reversed(top)) else: output.append(top) return output ## My walker def test_walk(e): #lxml Element comes in obj = ebag_get(e)['obj'] #get a tag object l=obj.flatwalk() ll= flatten(l) #No current solution to get 'parent' in this iterator #ie. for parent, child in ... for tag in ll: print tag Here's one of my Tag objects: class Brancher(object): def __init__(self, elem): self.elem = elem self.children = [] def flatwalk(self): l=[self] for child in self.children: l.append( child.flatwalk() ) #recur(ish)ion here return l class G( Brancher ): #Object for tags. pass \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking deeply nested lists
On 28/08/2010 08:43, Peter Otten wrote: If you call functions within functions (or methods, it doesn't matter) they consume stack space Right, got it. Darn, but at least there's that setrecursionlimit call. Thanks, \e -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking deeply nested lists
On 28/08/2010 09:21, Arnaud Delobelle wrote: This flattens the list in the flatwalk method (which IMHO it should do given its name!): Heh, I often name things ahead of my actual capacity to implement them! el is child.flatwalk(): Ah, I see what you mean. I think 'is' is 'in', but I kind of get the idea. This turns it into a generator method: And thanks for the generator versions too. I shall hack them in and poke them with a stick. Of course, for the above to work, "leaf" objects need a modified flatwalk method, e.g.: Yes, My 'stubs' (leaves) do have such, but I will edit to use yield. Thanks a mill. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking deeply nested lists
On 28/08/2010 11:17, Carl Banks wrote: It's simple. Copy the object to flatten onto your stack. Pop one item off the stack. If the item you popped is a list, push each item of that list onto the stack. Otherwise yield the value. Loop until stack is empty. Nice. The reversed thing was throwing me, but I think it's so that what comes first in a list will thus come first (on the end) of the stack. So I'm not suggesting that recursion be avoided (I've probably written a dozen recursive functions in the last week), I'm just saying sometimes it makes sense to use iteration even for problems recursion is tailor-made for. Thanks for that. In parsing the XML (using lxml) I actually did my own stack thing with while loops, to build the entire Tag object 'tree' — just because I wanted to see how to do it sans recursion. I still get cold shakes when I scroll past that monster! On the subject of recursion, and looking at my OP object model: the Tag objects that model the tags in an SVG file; how would I 'walk' the object tree without employing recursion? I am stuck on the eventual need to call child.flatwalk() and bang! there's recursion. I get the sense that it would be an external walk() function that does some stackery-trickery and reuturns/yields the tree/branch — all divorced from the actual objects. So, no flatwalk() methods needed at all. This kind of bothers me because it's nice to have objects 'know' what to do and addressing their siblings and children seems a vital part of that. Look at the case of asking a Tag for its XML source: Say g is a G() instance: print g.get_xml(), would have to do some string churning (specific to a g tag) and then start walking its children and ask them to do specific string stuff (in their contexts). This means I have short methods in each Tag instance that "know" how to represent themselves as XML and they can return that value. If I divorce the thing, it becomes a large loop with a lot of switchy-ifs to engage various blocks of string-fu. I hope that made sense. I can post my code if that would help. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking deeply nested lists
On 28/08/2010 12:03, Peter Otten wrote: But be warned that if you set the limit too high instead of giving you a RuntimeError your program will segfault. Silly question: is there any way to tell the future in this case? I mean, ask for X recursion limit, and catch an error (or something) if that won't fly. \d -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking deeply nested lists
On 28/08/2010 14:41, Peter Otten wrote: BTW, I didn't expect it but I get different results on different runs. Clever code. I will give it a go soonest. Elec off for the next 24 hours in my neck of the woods. Urgh. Python can't "import electricity" just yet :) \d -- http://mail.python.org/mailman/listinfo/python-list
Re: [RFC] Parametric Polymorphism
In article <[EMAIL PROTECTED]>, Catalin Marinas <[EMAIL PROTECTED]> wrote: ... > Of course, duck-typing is simple to use but the parametric > polymorphism is useful when the types are unrelated. Let's say you > want to implement a colour-print function which should support basic > types like ints and floats as well as lists and dictionaries. In this > case, and thank to the function decorations support, the code would be > clearer. What you're describing (and implementing) is not what I would call parametric polymorphism, though. See http://en.wikipedia.org/wiki/Polymorphism_(computer_science) You're talking about "ad-hoc" polymorphism. Personally, I can't agree that, in principle, this practice makes code clearer. In more common, less formal implementations you get functions like this -- def dosome(cmd): if type(cmd) == StringType: cmd = [cmd] ... Of course the first problem with this that it unnecessarily constrains the input type: if your API supports a string parameter, then in Python you should expect any value to work that supports string operations. This isn't a hypothetical matter, you can see relatively major Python applications have trouble with Unicode for exactly this reason. Secondly, rather than clarify the API, it confuses it. How many programmers will observe this usage and erroneously assume that dosome() _just_ takes a string, when the list parameter may in fact be the more ideal usage? This isn't hypothetical either. Your example is a fine one, and some kind of table to resolve the function according to type of input argument is a good idea. I'm just saying that more general application of this idea is best left to languages like C++. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: "no variable or argument declarations are necessary."
In article <[EMAIL PROTECTED]>, Steve Holden <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > Antoon Pardon <[EMAIL PROTECTED]> writes: > > > >>>Or you just code without declaring, intending to go > >>>back and do it later, and invariably forget. > >> > >>What's the problem, the compilor will allert you > >>to your forgetfullness and you can then correct > >>them all at once. > > > > > > Thiat in fact happens to me all the time and is an annoying aspect of > > Python. If I forget to declare several variables in C, the compiler > > gives me several warning messages and I fix them in one edit. If I > > forget to initialize several variables in Python, I need a separate > > test-edit cycle to hit the runtime error for each one. > > Well I hope you aren't suggesting that declaring variables makes it > impossible to forget to initalise them. So I don;t really see the > relevance of this remark, since you simply add an extra run to fix up > the "forgot to declare" problem. After that you get precisely one > runtime error per "forgot to initialize". It's hard to say what anyone's suggesting, unless some recent utterance from GvR has hinted at a possible declaration syntax in future Pythons. Short of that, it's ... a universe of possibilities, none of them likely enough to be very interesting. In the functional language approach I'm familiar with, you introduce a variable into a scope with a bind - let a = expr in ... do something with a and initialization is part of the package. Type is usually inferred. The kicker though is that the variable is never reassigned. In the ideal case it's essentially an alias for the initializing expression. That's one possibility we can probably not find in Python's universe. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: "no variable or argument declarations are necessary."
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bengt Richter) wrote: > On Tue, 04 Oct 2005 10:18:24 -0700, Donn Cave <[EMAIL PROTECTED]> wrote: > [...] > >In the functional language approach I'm familiar with, you > >introduce a variable into a scope with a bind - > > > > let a = expr in > > ... do something with a > > > >and initialization is part of the package. Type is usually > >inferred. The kicker though is that the variable is never > >reassigned. In the ideal case it's essentially an alias for > >the initializing expression. That's one possibility we can > >probably not find in Python's universe. > > > how would you compare that with > lambda a=expr: ... do something (limited to expression) with a > ? OK, the limitations of a Python lambda body do have this effect. But compare programming in a language like that, to programming with Python lambdas? Maybe it would be like living in a Zen Monastery, vs. living in your car. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: new forum -- homework help/chit chat/easy communication
Quoth Lasse_Vgsther_Karlsen <[EMAIL PROTECTED]>: | Brandon K wrote: |> Hrm...i find it demeaning to relegate Python to a scripting language |> while Visual Basic is in the "software development" section. Python so |> outdoes VB in every way shape and form. | | | In that respect I would very much like to see a definition of "scripting | language" as well :) | | In other words, what is the difference between a "scripting language" | and a "programming language". I oculd come up with a definition, but I can't come up with _the_ definition. The word is used in such broad and vague ways that to use it is practically a sign of sloppy thinking. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: new forum -- homework help/chit chat/easy communication
Quoth Mike Meyer <[EMAIL PROTECTED]>: | Lasse Vågsæther Karlsen <[EMAIL PROTECTED]> writes: ... |> I think that at one time, scripting languages was something that lived |> within other programs, like Office, and couldn't be used by themselves |> without running it inside that program, and as thus was a way to add |> minor functions and things to that program. | | That's certainly one kind of scripting language. But I don't think | it's ever been the only kind - shells have always been stand-alone | applications. What they have in common with your definition is that | both types of languages are used to capture user actions for later | repetition. And that's what makes a scripting language: it's a | language in which one writes "scripts" that describe actions - | normally taken by a user - so that a series of them can be performed | automatically. I don't think the shell is any exception - I think it's reasonable to see it as a control+UI language embedded in the UNIX operating system. It wouldn't really be a very useful stand-alone application on a computer platform without the same basic properties. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
Quoth "Fredrik Lundh" <[EMAIL PROTECTED]>: | Alex Stapleton wrote | | > Except it is interpreted. | | except that it isn't. Python source code is compiled to byte code, which | is then executed by a virtual machine. if the byte code for a module is up | to date, the Python runtime doesn't even look at the source code. Fair to say that byte code is interpreted? Seems to require an application we commonly call an interpreter. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Donn Cave wrote: > > > | > Except it is interpreted. > > | > > | except that it isn't. Python source code is compiled to byte code, which > > | is then executed by a virtual machine. if the byte code for a module is > > | up > > | to date, the Python runtime doesn't even look at the source code. > > > > Fair to say that byte code is interpreted? Seems to require an > > application we commonly call an interpreter. > > well, the bytecode isn't Python (the transformation isn't exactly straight- > forward, as we've seen in other posts I've made today). > > and even if the bytecode engine used in CPython can be viewed as an inter- > preter, does that make Python an interpreted language? what about Python > code that uses a runtime that converts it to machine code? (e.g. Psycho, > Iron- > Python). is it still an interpreter if it generates machine code? Is what an interpreter? I am not very well acquainted with these technologies, but it sounds like variations on the implementation of an interpreter, with no really compelling distinction between them. When a program is deployed as instructions in some form other than native code executable, and therefore those instructions need to be evaluated by something other than the hardware, then that would be some kind of interpretation. I agree that there are many shades of grey here, but there's also a real black that's sharply distinct and easy to find -- real native code binaries are not interpreted. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess and non-blocking IO (again)
In article <[EMAIL PROTECTED]>,
Marc Carter <[EMAIL PROTECTED]> wrote:
> I am trying to rewrite a PERL automation which started a "monitoring"
> application on many machines, via RSH, and then multiplexed their
> collective outputs to stdout.
>
> In production there are lots of these subprocesses but here is a
> simplified example what I have so far (python n00b alert!)
> - SNIP -
> import subprocess,select,sys
>
> speakers=[]
> lProc=[]
>
> for machine in ['box1','box2','box3']:
> p = subprocess.Popen( ('echo '+machine+';sleep 2;echo goodbye;sleep
> 2;echo cruel;sleep 2;echo world'), stdout=subprocess.PIPE,
> stderr=subprocess.STDOUT, stdin=None, universal_newlines=True )
> lProc.append( p )
> speakers.append( p.stdout )
>
> while speakers:
> speaking = select.select( speakers, [], [], 1000 )[0]
> for speaker in speaking:
> speech = speaker.readlines()
> if speech:
> for sentence in speech:
> print sentence.rstrip('\n')
> sys.stdout.flush() # sanity check
> else: # EOF
> speakers.remove( speaker )
> - SNIP -
> The problem with the above is that the subprocess buffers all its output
> when used like this and, hence, this automation is not informing me of
> much :)
You're using C stdio, through the Python fileobject. This is
sort of subprocess' fault, for returning a fileobject in the
first place, but in any case you can expect your input to be
buffered. You're asking for it, because that's what C stdio does.
When you call readlines(), you're further guaranteeing that you
won't go on to the next statement until the fork dies and its
pipe closes, because that's what readlines() does -- returns
_all_ lines of output.
If you want to use select(), don't use the fileobject
functions. Use os.read() to read data from the pipe's file
descriptor (p.stdout.fileno().) This is how you avoid the
buffering.
> This topic seems to have come up more than once. I am hoping that
> things have moved on from posts like this:
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/5472ce95e
> b430002/434fa9b471009ab2?q=blocking&rnum=4#434fa9b471009ab2
> as I don't really want to have to write all that ugly
> fork/dup/fcntl/exec code to achieve this when high-level libraries like
> "subprocess" really should have corresponding methods.
subprocess doesn't have pty functionality. It's hard to say
for sure who said what in that page, after the incredible mess
Google has made of their USENET archives, but I believe that's
why you see dup2 there - the author is using a pty library,
evidently pexpect. As far as I know, things have not moved on
in this respect, not sure what kind of movement you expected
to see in the intervening month. I don't think you need ptys,
though, so I wouldn't worry about it.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python's Performance
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > Donn Cave <[EMAIL PROTECTED]> writes: > > I agree that there are many shades of grey here, but there's also a > > real black that's sharply distinct and easy to find -- real native > > code binaries are not interpreted. > > Except when they are. Many machines are microcoded, which means your > "real native code binary" is interpreted by a microcode program stored > in the control store. Most machines don't have a writeable control > store (WCS), so you generally can't change the interpreter, but that's > not always true. In the simple case, a WCS lets the vendor fix > "hardware" bugs by providing a new version of the microcode. In the > extreme cases, you get OS's in which the control store is part of the > process state, so different processes can have radically different > formats for their "native code binaries". > > Then there's the Nanodata QM-1, whose microcode was interpreted by > "nanocode". Fine -- given a Python Chip computer, Python programs are native code. It can use microcode, if that helps. The VAX/11 microcode was just a software extension of the CPU hardware, implementing some extra instructions, the way I remember it. I don't recall that it was of any more than academic interest to anyone using the computer - though it may have been software in a sense, it was on the hardware side of the wall. On the software side of the wall, if your program can go over the wall by itself, then it's native. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: tuple versus list
In article <[EMAIL PROTECTED]>, Bryan <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > In this particular case, it seems that (width,height) looks nicer. But > > I think otherwise, list constuct is easier to read, even though it is > > supposed to be slower. > > > > With list you can : > > [a] + [ x for x in something ] > > > > With tuple it looks like this : > > (a,) + tuple(x for x in something) > > > > I think the list looks cleaner. And since you cannot concat tuple with > > list, I think unless it looks obvious and natural(as in your case), use > > list. > > > > > i always use the structure analogy. if you view (width, height) as a > structure, > use a tuple. if you view it a sequence, use a list. in this example, i view > it > as a stucture, so i would use (width, height) as a tuple. Right, but there's an unfortunate ambiguity in the term "sequence", since in Python it is defined to include tuple. I gather you meant more in the abstract sense of a data collection whose interesting properties are of a sequential nature, as opposed to the way we are typically more interested in positional access to a tuple. Maybe a more computer literate reader will have a better word for this, that doesn't collide with Python terminology. My semi-formal operational definition is "a is similar to a[x:y], where x is not 0 or y is not -1, and `similar' means `could be a legal value in the same context.'" Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing an immutable object in python
In article <[EMAIL PROTECTED]>, "Mapisto" <[EMAIL PROTECTED]> wrote: > I've noticed that if I initialize list of integers in the next manner: > > >>> my_list = [0] * 30 > > It works just fine, even if I'll try to assign one element: > > >>> id( my_list[4] ) > 10900116 > >>> id( my_list[6] ) > 10900116 > >>> my_list[4] = 6 > >>> id( my_list[4] ) > 10900044 > >>> id( my_list[6] ) > 10900116 > > The change in the poision occurs becouse int() is an immutable object. > > if I will do the same with a user-defined object, This reference > manipulating will not happen. So, every entry in the array will refer > to the same instance. Not at all. If you do the same thing, class C: pass c = C() a = [c]*12 ... etc., you should observe the same pattern with respect to object identities. Mutability doesn't really play any role here. > Is there a way to bypass it (or perhaps to write a self-defined > immutable object)? Bypass what? What do you need? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Run process with timeout
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Alex Martelli) wrote: > Micah Elliott <[EMAIL PROTECTED]> wrote: [... re problem killing children of shell script ...] > > Is there any way to enable Python's subprocess module to do (implicit?) > > group setup to ease killing of all children? If not, is it a reasonable > > RFE? > > Not as far as I know. It might be a reasonable request in suitable > dialects of Unix-like OSes, though. A setpgrp call (in the callback > which you can request Popen to perform, after it forks and before it > execs) might suffice... except that you can't rely on children process > not to setpgrp's themselves, can you?! I bet that wouldn't be a problem, though. subprocess.Popen constructor takes a preexec_fn parameter that looks like it might be a suitable place to try this. (Interesting that it's a function parameter, not a method to be overridden by a subclass.) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: KeyboardInterrupt vs extension written in C
Quoth "Tamas Nepusz" <[EMAIL PROTECTED]>: | No, that's actually a bit more complicated. The library I'm working on | is designed for performing calculations on large-scale graphs (~1 | nodes and edges). I want to create a Python interface for that library, | so what I want to accomplish is that I could just type "from igraph | import *" in a Python command line and then access all of the | functionalities of the igraph library. Now it works, except the fact | that if, for example, I start computing the diameter of a random graph | of ~10 nodes and ~20 edges, I can't cancel it, because the | KeyboardInterrupt is not propagated to the Python toplevel (or it isn't | even generated until the igraph library routine returns). I would like | to allow the user to cancel the computation with the usual Ctrl-C and | return to the Python interactive interface. | This whole feature is not vital, but it would mean a big step towards | user-friendliness. | I have access to the source code of igraph as well (since one of my | colleagues is developing it), so another possible solution would be to | inject some calls into the igraph source code which temporarily cancels | the computation and checks whether there's something waiting in the | Python interpreter, but I haven't found any function in the API which | allows me to do this. Hm, tough question. Even in C, this would be a little awkward. If you only wanted the program to abort on ^C, then you could just replace the default sigint handler with SIG_DFL. But then you'd be back to the shell prompt, not the python prompt. If you want to catch the signal, but also abort a computation, then as you say, the computation needs to check periodically. Rather than peek into Python for this, I'm wondering if your module could set its own signal handler for SIGINT, which would set a library flag. Then call PyErr_SetInterrupt(), to emulate the normal signal handler. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Read/Write from/to a process
Quoth "jas" <[EMAIL PROTECTED]>: | Steve Holden wrote: |> Look at how you might do it in other languages. Then you'll realise this |> isn't (just) a Python problem. | | Yea your right. However, for example, in Java, one can use the Process | class, and then read from the stream until its the end (i.e. -1 is | returned). However, with Python when reading from | subprocess.Popen.stdout ...I don't know when to stop (except for | looking for a ">" or something). Is there a standard, like read until | "-1" or something? Sure, end of file is '', a string with 0 bytes. That means the other end of the pipe has closed, usually due to exit of the other process that was writing to it. Not much help for you there, nor would the Java equivalent be, I presume. Even on UNIX, where pipes are a mainstay of ordinary applications, this one would very likely need a pseudotty device instead, to prevent C library block buffering, and it would still be difficult and unreliable. Ironically the best support I've seen came from a platform that didn't use pipes much at all, VAX/VMS (I put that in the past tense because for all I know it may have evolved in this respect.) The pipe-like VMS device was called a "mailbox", and the interesting feature was that you could be notified when a read had been queued on the device. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: popen2
Quoth Pierre Hanser <[EMAIL PROTECTED]>:
| Grant Edwards a écrit :
|> On 2005-10-29, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
|>>>>>>>"g.franzkowiak" <[EMAIL PROTECTED]> (gf) wrote:
|>>
|>>>gf> If starts a process with popen2.popen3('myprogram') and myprogram.exe is
|>>>gf> running before, I've a connection to the second process, not to the
first.
|>>>gf> I can find the process by name before I start a process with popen2...,
|>>>gf> but how bcan I connect t this process with a pipe ?
|>>
|>>You have to use a named pipe.
|>
|>
|> That would require that the application know about the named
|> pipe and open it. I don't think there is any way to swap a
|> pipe in for stdin/stdout once a process is running.
|>
| in C: freopen
Hello, it seems fairly clear that the stdin/stdout in question belongs
to another process, which cannot be instructed at this point to execute
freopen(). If there's a way to do this, it will be peculiar to the
platform and almost certainly not worth the effort.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Rich __repr__
In article <[EMAIL PROTECTED]>,
Ben Finney <[EMAIL PROTECTED]> wrote:
> Erik Max Francis <[EMAIL PROTECTED]> wrote:
> > Ben Finney wrote:
> > > If I want to implement a __repr__ that's reasonably "nice" to the
> > > programmer, what's the Right Way? Are there recipes I should look
> > > at?
> >
> > I tend to use:
> >
> > def __repr__(self):
> > if hasattr(self, '__str__'):
> > return '<%s @ 0x%x (%s)>' % (self.__class__.__name__,
> > id(self), str(self))
> > else:
> > return '<%s @ 0x%x>' % (self.__class__.__name__, id(self))
>
> Well that just begs the question: what's a good way (or a Right Way,
> if that exists) to write a __str__ for a complex class?
Well, in my opinion there pretty much isn't a good way. That is,
for any randomly selected complex class, there probably is no
worthwhile string value, hence no good __str__.
This dives off into a certain amount of controversy over what
repr and str are ideally supposed to do, but I think everyone
would agree that if there's an "represent object for programmer"
string value, it's the repr. So the str is presumably not for
the programmer, but rather for the application, and I'm just
saying that for application purposes, not all objects can usefully
be reduced to a string value.
Meanwhile, the code above also raises some questions where str
is already provided. Run it on your subclass-of-str object and
give the object a value of ') hi ('. This is why containers
use repr to render their contents, not str.
> It could be done just by hacking __repr__ with whatever things seem
> appropriate, in some ad-hoc format. Or, as I'm hoping with this
> thread, there may be common practices for outputting object state from
> __repr__ that are concise yet easily standardised and/or recognised.
I guess the best I could suggest is to stick with the format
already used by instances (<__main__.C instance at 0x71eb8>)
and augment it with class-specific information.
def make_repr(self, special):
return '<%s instance at 0x%x: %s>' % (self.__class__.__name__,
id(self), special)
def __repr__(self):
return self.make_repr(repr(self.my_favorite_things))
This omits the module qualifier for the class name, but
arguably that's a bit of a nuisance anyway. If there's a
best, common practice way to do it, I wouldn't care to pose
as an expert in such things, so you have to decide for yourself.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Class Variable Access and Assignment
In article <[EMAIL PROTECTED]>, Magnus Lycka <[EMAIL PROTECTED]> wrote: ... > On the other hand: > > >>> class C: > ... a = [1] > ... > >>> b=C() > >>> b.a += [2] > >>> b.a > [1, 2] > >>> C.a > [1, 2] > > I can understand that Guido was a bit reluctant to introduce > += etc into Python, and it's important to understand that they > typically behave differently for immutable and mutable objects. As far as I know, Guido has never added a feature reluctantly. He can take full responsibility for this misguided wart. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: O_DIRECT on stdin?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Here's some text from my open(2) manpage: > Transfer sizes, and the alignment of user buffer and file offset must > all > be multiples of the logical block size of the file system. Does that apply in the example he gave, < /dev/sda1 ? It seems to me this would not go through any filesystem anyway. That might account for the "invalid argument" error, but at any rate it would be irrelevant. Plus it doesn't seem to score very high on portability, according to the Linux man page I'm looking at -- apparently not a POSIX or any such standard, just borrowed from Irix in recent Linux versions, and FreeBSD with slightly different behavior. Don't see any trace of it in NetBSD, MacOS X. > It's unlikely that in practice you can get Python's sys.stdin.read() or > os.read() to reliably use a buffer that fits the alignment restriction. Though of course os.read() would eliminate one layer of buffering altogether. Might be worth a try. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Addressing the last element of a list
Quoth Steven D'Aprano <[EMAIL PROTECTED]>: ... | So when working with ints, strs or other immutable objects, you aren't | modifying the objects in place, you are rebinding the name to another | object: | | py> spam = "a tasty meat-like food" | py> alias = spam # both names point to the same str object | py> spam = "spam spam spam spam" # rebinds name to new str object | py> print spam, alias | 'spam spam spam spam' 'a tasty meat-like food' The semantics of assignment are like that, period. If the right hand side is an int, a string, a class instance, a list, whatever, doesn't matter at all. The question of mutability at this point can be a red herring for someone who doesn't already understand these matters. Mutability is nothing special, it's just a feature built into the object type -- in general, the ability to store some state. This is of course useful in situations where we want to propagate state changes, so it naturally comes up in this context, but language per se does not observe any distinction here so far as I know. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Addressing the last element of a list
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: ... > Most OO languages do the name/variable thing, but some of the popular > ones aren't consistent about it, giving some types "special" status, > so that sometimes "a = b" causes b to be copied onto a, and sometimes > it causes a to become a pointer to b. I find a consistent approach is > preferable. Who wouldn't. > Most OO languages also have the mutable/immutable object thing. The > set of which objects are immutable changes from language to > language. It's really only relevant in this case because the solution > to "I want to change an alias" issue involves using a mutable object. Yes, and furthermore it's only vaguely relevant. I mean, it really requires a particular kind of mutability, where one object can store a reference to another. That's easy to find in core object types, and of course it is a kind of mutability, but it isn't the definition of mutable. So we drag out this terminology, that neither clearly nor accurately describes the functionality we have in mind, and then we make some vague or even wrong statement about its relationship to the issue. It has been going on for years, usually I believe from people who understand quite well how it really works. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: running functions
Quoth Grant Edwards <[EMAIL PROTECTED]>: | On 2005-11-18, Scott David Daniels <[EMAIL PROTECTED]> wrote: | > Gorlon the Impossible wrote: | > | >> I have to agree with you there. Threading is working out great for me | >> so far. The multiprocess thing has just baffled me, but then again I'm | >> learning. Any tips or suggestions offered are appreciated... | > | > The reason multiprocess is easier is that you have enforced | > separation. Multiple processes / threads / whatever that share | > reads and writes into shared memory are rife with | > irreproducible bugs and untestable code. | | There can be problems, but you make it sound way worse than it | really is. I've been doing threaded SW for a lot of years | (yikes! almost 25), and it's just not that hard to deal with | shared objects/variables -- especially in Python with its GIL. | | I think it's easier and more intuitive than forking. | | I've written a lot of (admittedly not huge) Python programs | using threading (some with 30-40 thread), and I don't remember | ever tripping over anything significant. I think dealing with | shared objects is easier than figuring out how to do | inter-process communications using sockets or Posix shared | memory or whatnot. It's not difficult if you don't have to do | any communication between processes, but in that case, shared | objects aren't a problem either. To understand the point behind this, it's important to understand what easy and difficult are about here. Are we talking about easy to get something done? Easy to get something absolutely reliable? Easy to screw up? The point is not that it's hard to import the threading module and fire off a thread to do something. On the contrary, if anything maybe it's too easy. The thing that's supposed to be difficult is predictable, reliable execution, in in principle because of a compounding effect on the number of possible states. It should be scary. Whether it should be prohibitively scary is the kind of abstract debate that will never really be resolved here. I got into BeOS when it came out a few years back, and learned to program in Python to its native UI, where each window has its own thread. It works fine for me, and I personally support the decision to do it that way, but later there was a school of thought, including some ex-Be engineers among the proponents, that held it to be a big mistake. Apparently this was after all a common pitfall for application developers, who would release code that could deadlock or go wrong in various ways due to unanticipated thread interactions. All of these application developers were working in C++, and I'm sure that made them a little more vulnerable. Thank heavens Python isn't capable of real concurrent execution, for one thing, and also it's surely easier to put together generic functions for queueing and that sort of thing, so I could afford to be more disciplined about sharing data between threads. But in the end there were a lot more of them, their applications were bigger or more adventurous and more widely used, so there were a lot of opportunities for things to happen to them that have never happened to me. As I said, I thought their design was good, but maybe they just didn't get the word out like they should have - that threads are scary. Donn Cave, [EMAIL PROTECTED] (posting this from a Python/BeOS API newsreader) -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding through recursion
In article <[EMAIL PROTECTED]>, Ben Finney <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > def add(x, y): > > if x == 0: > > print y > > return y > > else: > > x -= 1 > > y += 1 > > add(x, y) ... > def recursive_add(x, y): > if x == 0: > print y > result = y > else: > x -= 1 > y += 1 > result = recursive_add(x, y) > return result > > I find this much less error-prone than hiding return statements in > branches throughout the function; if the only return statement is at > the very end of the function, it becomes much easier to read. Well, it's sure clearer where it returns. On the other hand, now you have to analyze the block structure to know that the 3rd line assignment is still going to be in effect when you get to the return. That's easy in this case, of course, but make the structure more complex and add a loop or too, and it can be hard. Where if you see a return statement, you know for sure. State variables are analogous to goto in a way, similar sort of spaghetti potential. It may or may not help to have all the strands come out at the same spot, if the route to that spot could be complicated. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: ownership problem?
In article <[EMAIL PROTECTED]>, Jeffrey Schwab <[EMAIL PROTECTED]> wrote: ... > Yes it is. Memory is only one type of resource. There are still files > and sockets to close, pipes to flush, log messages to be printed, GDI > contexts to free, locks to release, etc. In C++, these things are > generally done by destructors, which are called automatically and > deterministically. I am not a Python Guru, but in Perl, Java, and other > languages that have built-in garbage collectors, these tasks have to be > done explicitly. I find that this forces a procedural approach, even in > an otherwise object-oriented program. > > If you want something like automatic garbage collection in C++, I > recommend the use of Factories with destructors that release the > Factories' products. The zeitgeist in c.l.c++.moderated seems to prefer > the use of smart (reference-counted) pointers, which also rely on > destructors to release resources automatically. Plentry of free, > open-source implementations are available. You may be gratified to learn that Python's main storage model is reference counted objects, and when an object falls out of all referenced scopes its finalizers run immediately. This is however true only of the C implementation. The Java implementation naturally has Java's limitations in this matter, so documentation generally avoids the issue. The C implementation has been around for over a decade, wonder if it had any influence on your C++ zeitgeist? Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.4.2 on AIX 4.3 make fails on threading
Quoth Paul Watson <[EMAIL PROTECTED]>: | When I try to build 2.4.2 on AIX 4.3, it fails on missing thread | objects. I ran ./configure --without-threads --without-gcc. | | Before using --without-threads I had several .pthread* symbols missing. | I do not have to have threading on this build, but it would be helpful | if it is possible. The machine has the IBM C compiler. Can anyone | suggest a configuration or some change that I can make to cause this to | build correctly? Thanks. | | $ xlc 2>&1|head -1 |VisualAge C++ Professional / C for AIX Compiler, Version 5 In earlier compilers, and I think this one too, "cc_r" (instead of "xlc") gives you the thread options and libraries. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: pipe related question
In article <[EMAIL PROTECTED]>, David Reed <[EMAIL PROTECTED]> wrote: > Is there any way to have one program run another arbitrary program > with input from stdin and display the output as if you had run it in > a shell (i.e., you'd see some of the output followed by the input > they typed in and then a newline because they pressed return followed > by subsequent output, etc.). > > I can't use readline with the pipe because I don't know how much > output the arbitrary program has before it calls an input statement. > I've googled and understand that calling read() will deadlock when > the program is waiting for input. > > When I first write all the input to the input pipe and then call read > on the output pipe it works just the same as if I had run the program > as: program < input_file > > What I'd like to see is the input intermixed with the output as if > the user had typed it in. It sounds like there may be two problems here. You may need to go to some extra lengths to get the arbitrary program to adopt a convenient buffering strategy. I'm sure you have come across plenty of discussion of this problem in your review of the old traffic in this group, since it comes up all the time. The usual answer is to use a pseudotty device instead of a regular pipe. I don't know what's currently popular for Python support of this device, but there's builtin support on some platforms, cf. os.openpty and os.forkpty. It may be convenient in your case to turn ECHO on. The other problem is more intractable. If you want to know for sure when the arbitrary program expects input, well, UNIX doesn't support that. (Can you run your application on VMS?) The only thing I can think of is a select() with timeout, with some compromise value that will allow most outputs to complete without stalling longer than is really convenient. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: exception KeyboardInterrupt and os.system command
In article <[EMAIL PROTECTED]>,
"malv" <[EMAIL PROTECTED]> wrote:
> That's also kind of what I expected.
> However, I quickly tried:
> import os
> while 1:
> y = os.system("sleep 1")
> z = (y >> 8) & 0xFF
> print z
>
> I never get anything in return but 0, hitting c-C or not.
> I have uset the above code to get exit code returns in the past though.
> Would there be anything special with sleep?
That algorithm will give you the same thing as os.WEXITSTATUS(),
on most platforms, though not necessarily all so it's better
to use the function.
On platforms where it works, exit status is of course stored in
2nd byte from the low end, and signal status is stored separately,
in the low byte. So naturally, your right shift discards the
signal status and you're left with 0.
On the other hand, if you use os.spawnv, signal status will
be returned as a negative integer, instead of a positive
integer exit status. spawnv() is safer than system() if the
command is constructed from data, and it also doesn't block
SIGINT in the caller like system does, so it would work for
the problem posed in the original post.
But it might be just as well to watch the process status for
any non-zero value, and then call the graceful exit procedure.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: python speed
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > "Harald Armin Massa" <[EMAIL PROTECTED]> writes: > >>Faster than assembly? LOL... :) > > why not? Of course, a simple script like "copy 200 bytes from left to > > right" can be handoptimized in assembler and run at optimum speed. > > Maybe there is even a special processor command to do that. > > Chances are, version 1 of the system doesn't have the command. Version > 2 does, but it's no better than the obvious hand-coded loop. Version 3 > finally makes it faster than the hand-coded loop, if you assume you > have the instruction. If you have to test to see if you can use it, > the hand-coded version is equally fast. Version 4 makes it faster even > if you do the test, so you want to use it if you can. Of course, by > then there'll be a *different* command that can do the same thing,j and > is faster in some conditions. > > Dealing with this in assembler is a PITA. If you're generating code on > the fly, you generate the correct version for the CPU you're running > on, and that's that. It'll run at least as fast as hand-coded > assembler on every CPU, and faster on some. Actually I think the post you quote went on to make a similar point. I read yesterday morning in the paper that the Goto Basic Linear Algebra Subroutines, by a Mr. Kazushige Goto, are still the most efficient library of functions for their purpose for use in supercomputing applications. Apparently hand-optimized assembler for specific processors. http://seattlepi.nwsource.com/business/250070_goto29.html (actually from the NY Times, apparently) Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Quoth [EMAIL PROTECTED]: | Christoph Zwerschke wrote: ... |> Sorry, but I still do not get it. Why is it a feature if I cannot count |> or find items in tuples? Why is it bad program style if I do this? So |> far I haven't got any reasonable explanation and I think there is no. | | I have no idea, I can understand their view, not necessarily agree. And | reasonable explanation is not something I usually find on this group, | for issues like this. It's hard to tell from this how well you do understand it, and of course it's hard to believe another explanation is going to make any difference to those who are basically committed to the opposing point of view. But what the hell. Tuples and lists really are intended to serve two fundamentally different purposes. We might guess that just from the fact that both are included in Python, in fact we hear it from Guido van Rossum, and one might add that other languages also make this distinction (more clearly than Python.) As I'm sure everyone still reading has already heard, the natural usage of a tuple is as a heterogenous sequence. I would like to explain this using the concept of an "application type", by which I mean the set of values that would be valid when applied to a particular context. For example, os.spawnv() takes as one of its arguments a list of command arguments, time.mktime() takes a tuple of time values. A homogeneous sequence is one where a and a[x:y] (where x:y is not 0:-1) have the same application type. A list of command arguments is clearly homogeneous in this sense - any sequence of strings is a valid input, so any slice of this sequence must also be valid. (Valid in the type sense, obviously the value and thus the result must change.) A tuple of time values, though, must have exactly 9 elements, so it's heterogeneous in this sense, even though all the values are integer. One doesn't count elements in this kind of a tuple, because it's presumed to have a natural predefined number of elements. One doesn't search for values in this kind of a tuple, because the occurrence of a value has meaning only in conjunction with its location, e.g., t[4] is how many minutes past the hour, but t[5] is how many seconds, etc. I have to confess that this wasn't obvious to me, either, at first, and in fact probably about half of my extant code is burdened with the idea that a tuple is a smart way to economize on the overhead of a list. Somewhere along the line, I guess about 5 years ago? maybe from reading about it here, I saw the light on this, and since then my code has gotten easier to read and more robust. Lists really are better for all the kinds of things that lists are for -- just for example, [1] reads a lot better than (1,) -- and the savings on overhead is not worth the cost to exploit it. My tendency to seize on this foolish optimization is however pretty natural, as is the human tendency to try to make two similar things interchangeable. So we're happy to see that tuple does not have the features it doesn't need, because it helps in a small way to make Python code better. If only by giving us a chance to have this little chat once in a while. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
In article <[EMAIL PROTECTED]>, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > > Steve Holden <[EMAIL PROTECTED]> wrote: > >... > > > Presumably because it's necessary to extract the individual values > > > (though os.stat results recently became addressable by attribute name as > > > well as by index, and this is an indication of the originally intended > > > purpose of tuples). > > > > Yep -- "time tuples" have also become pseudo-tuples (each element can be > > accessed by name as well as by index) a while ago, and I believe there's > > one more example besides stats and times (but I can't recall which one). > > > > Perhaps, if the tuple type _in general_ allowed naming the items in a > > smooth way, that might help users see a tuple as "a kind of > > ``struct''... which also happens to be immutable". There are a few such > > "supertuples" (with item-naming) in the cookbook, but I wonder if it > > might not be worth having such functionality in the standard library > > (for this clarification as well as, sometimes, helping the readability > > of some user code). > > iirc, providing a python-level API to the SequenceStruct stuff > has been proposed before, and rejected. > > (fwiw, I'm not sure the time and stat tuples would have been > tuples if the standard library had been designed today; the C- > level stat struct doesn't have a fixed number of members, and > the C-level time API would have been better off as a light- > weight "time" type (similar to sockets, stdio-based files, and > other C-wrapper types)) Right. After devoting a lengthy post to the defense of tuples as a structured type, I have to admit that they're not a very good one - it's hard to think of many structured values that are ideally expressed by a fixed length vector with elements accessed by integer index. Another theme that occasionally comes up in advice from the learned has been "use a class". Of course for values that are related to some external structure, you'd want to provide something to make tuple(a) work, serialization etc., and you'd probably end up with something a lot like StructSequence. Meanwhile losing a significant overhead. I wrote a quickie Python API to SequenceStruct and used it to make an (x, y) coord type, to compare with a Coord.x,y class. A list of a million coords used 1/5 space, and took 1/10 the time to create. Hm. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
In article <[EMAIL PROTECTED]>, Rocco Moretti <[EMAIL PROTECTED]> wrote: > People who argue that "frozen list" is not needed because we already > have the tuple type, while simultaneously arguing that tuples shouldn't > grow list methods because they are conceptually different from lists > will be bludgeoned to death with a paradox. :) Maybe I can dodge the paradox by noting that the set of things we need, is much larger than the set of things we need enough to do what it takes to get them. So I can agree that frozen lists are needed, without necessarily supporting the effort. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: ... > So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work? > > Seriously. Why doesn't this have to be phrased as "for x in list((1, > 2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.? How could list(t) work, if for x in t didn't? For me, conceptually, if an object can't be accessed sequentially, then it can't be mapped to a sequence. Anyway, it seems to me that in the end this is about that balance between practicality and purity. Maybe it's more like tuples have a primary intended purpose, and some support for other applications. Not white, but not pure black either. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
In article <[EMAIL PROTECTED]>, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > There's a historical issue too: when tuples started first being > used this way in Python, classes had not yet been introduced. When was that, old-timer? According to Misc/HISTORY, Python was first posted to alt.sources at version 0.9.0, February 1991. It doesn't say 0.9.0 had classes, but at 0.9.3 we see refinements like __dict__, and it's hard to imagine that classes themselves snuck in without notice in the interim. If you got a copy of some older version than this, you have some interesting historical perspectives there, but not much of a historical issue, I'd say, without much going on in the way of a user community. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why use #!/usr/bin/env python rather than #!python?
In article <[EMAIL PROTECTED]>, Adriano Ferreira <[EMAIL PROTECTED]> wrote: > Hey, that's not fair. In your illustration above, does 'python' can be > found in the PATH? That is, > > $ python /tmp/hello.py > > works? If it does, probably > > #!/usr/bin/python > #!/usr/bin/env python > #!python > > would also work if > (1) 'python' is at '/usr/bin/python' (but that's inflexible) > (2) 'python' can be found in the environment variable path (if 'env' > is at '/usr/bin/env') > (3) 'python' can be found in the environment variable path (no need > for 'env' utility) Contrary to popular belief, #! is not intended for the shell, but rather for the execve(2) system call of the UNIX operating system. These two characters form the 16 bit "magic number" of interpreter files. Any executable file must start with a 16 bit field that identifies it so the operating system will know how to execute it. In the case of a #! interpreter file, the operating system expects the rest of that line to be the path to the file. PATH is not searched, and is irrelevant. The only way #!python can work, is if it's in the current working directory. Just to help make it confusing, when this mechanism fails and execve(2) returns an error, most shells will go on to try to execute the file themselves, regardless of whether there's a #! or not. csh (the shell language that doesn't look anything like C, Bill Joy's attempt at language design before he started over with Java) does that only if the first line is "#"; otherwise it invokes the Bourne shell. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
Quoth Mike Meyer <[EMAIL PROTECTED]>: | Donn Cave <[EMAIL PROTECTED]> writes: ... |> For me, conceptually, if an object can't be accessed |> sequentially, then it can't be mapped to a sequence. | | So you're saying that for should implicitly invoke list (or maybe | iter) on any object that it's passed that's not a list or iterator? Not really saying anything so concrete about it -- doesn't make any difference to me how it works, just saying that all these things come together. Convert to list, iterate, for. They're conceptually not just related, but bound together. |> Anyway, it seems to me that in the end this is about |> that balance between practicality and purity. Maybe |> it's more like tuples have a primary intended purpose, |> and some support for other applications. Not white, |> but not pure black either. | | If you do that, you've just weakened the case for not having count | etc. as methods of tuples. | | It really is the dichotomy of "tuples aren't meant to be sequences so | they don't have ..." versus being able to access them sequentially | that gets me. That just doesn't seem right. The case is weakened only if we have been pretending it was really strong. I guess this may be why this issue drives certain people crazy. There's a case for "don't have", but it isn't air-tight, so what do we do? Well, that's the one thing I really like about the winter holiday season -- some particularly flavorful ales come out of the local micro-breweries around this time of year, just in time to ease my worries about tuples. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: spawnle & umask
In article <[EMAIL PROTECTED]>, Yves Glodt <[EMAIL PROTECTED]> wrote: > David Wahler wrote: > > Yves Glodt wrote: > >> It does, I did like this: > >> > >> os.umask(0113) > >> newpid = > >> os.spawnl(os.P_NOWAIT,'/usr/local/bin/wine','/usr/local/bin/wine',executabl > >> e) > >> > >> But I wanted to use spawnle and it's env argument, to avoid setting > >> umask manually... > > > > The umask is not part of the environment, so there's no way to set it > > directly through spawnle. > > ok > > > Why don't you want to use os.umask? > > Only because I thought spawnle could set it through env... > But as it can't I will now go with os.umask. On UNIX, the "spawn" functions are just Python code that wraps up the low level fork and execve system calls. There's no reason you can't write your own version if you like, that does what you need. It does make sense to want to modify umask and who knows what other inheritable context in the fork, so you might be thinking of an API with a function that's called at that time, like spawnve(wait, file, args, env, func) The funny thing is, that's such a good idea that the implementation already has a function with that signature. The only difference is that func() also must call the appropriate execve function. So for example, def execumask113(file, args, env): os.umask(0113) return os.execve(file, args, env) ... os._spawnvef(os.P_NOWAIT, '/usr/local/bin/wine', ['wine', exe], os.environ, execumask113) Now the problem is that this function is evidently not part of the published API for os.py, so it would be unseemly to complain if it were to change in later versions. So I guess the right thing to do is write your own spawn function from the ground up. But at least you have some ideas there about how it might work. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: The Industry choice
Quoth Hans Nowak <[EMAIL PROTECTED]>: | Paul Rubin wrote: | |> You should write unit tests either way, but in Python you're relying |> on the tests to find stuff that the compiler finds for you with Java. | | As I wrote on my weblog a while ago, I suspect that this effect is | largely psychological. You jump through hoops, declaring types all over | the place, checking exceptions, working around the language's | limitations, etc. So when your code compiles, it *feels* safer. Like | you're at least part of the way towards ensuring correctness. All that | work must be good for *something*, right? Never mind that when writing | unit tests for a dynamic language, you don't check for these things at | all. How often do you explicitly check types in Python unit tests? | IMHO, when using a dynamic language, you don't need most of the checks | that Java, C# and their ilk force upon you. I have been fooling around with strongly, statically typed languages for a couple of years, in my spare time - Objective CAML, Haskell, O'Haskell. This is a little different experience than what you two are talking about - I don't think Java, C# and their ilk are quite as rigorous, nor do they use type inference - but as much as it would probably gag an FP enthusiast to say this, the basic idea is the same. I can only believe that if you think the benefit of static typing is psychological, either something is very different between the way you and I write programs, or you're not doing it right. For me, the effect is striking. I pound out a little program, couple hundred lines maybe, and think "hm, guess that's it" and save it to disk. Run the compiler, it says "no, that's not it - look at line 49, where this expression has type string but context requires list string." OK, fix that, iterate. Most of this goes about as fast as I can edit, sometimes longer, but it's always about structural flaws in my program, that got there usually because I changed my mind about something in midstream, or maybe I just mistyped something or forgot what I was doing. Then, when the compiler is happy -- the program works. Not always, but so much more often than when I write them in Python. Now you may repeat here that we all must make thorough unit testing a cornerstone of our Python programming, but don't tell me that the advantage of static typing is psychological. It does substantially improve the odds that a program will be correct when it runs, because I have seen it happen. If unit testing does so as well, then obviously there will be some redundancy there, but of course only where you actually have complete coverage from unit testing, which not everyone can claim and I'm sure even fewer really have. And like the man said, you're doing that work to find a lot of things that the compiler could have found for you. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
