Re: Faster GUI text control
On Fri, 13 May 2005 15:44:24 -0500, none wrote: I'm trying to decide what is the best replacement for the control. I was originally planning on redoing the GUI with wxpython, but I've seen people indicate I would have the same problem. Honestly, if this is important to you, the best thing to do is try all the ones relevant to your platform; generally creating a window with a text widget and loading it with a whole lotta text, as appropriate to your app, is fairly easy; it is not true that once you've tried one GUI toolkit you've tried them all, but each one is easier than the last, and generally, you can: * Use the tutorial up to where they place a widget. * Jump to the reference manual where they describe the text widget and insert it instead. * Fill the widget with a bunch of text. (some string\n*10 or something works well.) * Start the program and go. Not counting downloading, an hour each, tops. (The only tricky one that I am aware of is that GTK insists that text widgets have to be in a Scrolled Window to get a scrollbar on them.) The problem is that if you're really looking for performance, it may differ based on the characteristics of the text and the quality of the target computer, the platform (which you don't mention; GTK may scream in Linux and make you scream in Windows...), etc., and there may be no one person who can give you a firm This is the best solution for your situation answer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: The `print' statement over Unicode
On Sun, 08 May 2005 13:46:22 +, John J. Lee wrote: I don't mean to put words into Franois' mouth, but IIRC he managed, for example, GNU tar for some time and, while using some kind of tracking system under the covers, didn't impose it on his users. IMVHO, that was very nice of him, but I'd be reluctant to attempt to enforce this way of working on a hard-working and competent contributor to an open source project to which I'm not a core contributor myself. Then I'd honor his consistency of belief, but still consider it impolite in general, as asking someone to do tons of work overall to save you a bit is almost always impolite. -- http://mail.python.org/mailman/listinfo/python-list
Re: Listening to changes in a C++ variable from python
On Sat, 07 May 2005 07:16:58 -0700, lamthierry wrote: Is there some python method which can do the polling you are talking about? Or can you send me a link to some existing example? Take a moment to go back to the basics. C++ is, in general, a simple system. The *language* is complicated at times, but it does actually strive for no unknown magic taking place. When you say int i = 4, there is some literal value in memory somewhere taking the value of 4. If you say i = 5, that value in memory now says five. The reason you can't listen to this is quite literally because you RAM does not have that ability (for good reason); there are no circuits that are triggered when a value is changed. (I'm talking conventional RAM here, with no hardware mapping or anything else special.) Polling here simply means checking periodically. You don't need any special functions or libraries, you just need to check periodically. Your GUI system should have a system for creating timeouts, but without telling me what that is, I can't give the code. (*I* may not be able to even so; I have not used them all extensively enough to know about all the schedulers.) Your timeout function should simply check the new value and do the appropriate thing based on the new value. So, there isn't really a method, it's just combining your GUI scheduler with a simple == or or or whatever else is appropriate in your case. If it takes more than about four or five lines to write the basic poller, you're probably on the wrong track. (Correctly handling what the poller sees may be more complicated, but the periodic checking should be simple.) If you need more help (though I strongly suggest that you try to get the scheduler to do something two seconds from now or something, and after that it *should* be obvious what to do next), you'll need to include what GUI toolkit you are using, and possibly the current Python code that you are using to access the value you'd like the GUI to track. You may also want to explain how you are connecting the apps; is the C++ part and the Python part in one app in different threads, or are you using some other communication form? One warning: You might be tempted to use time.sleep(); don't do that. That works OK in a Python program where only your code is running, but in any GUI program the GUI itself is also running. Using time.sleep() will completely stop *everything* during the duration of the sleep, completely freezing the GUI as if it were locked up; that's why all GUIs have schedulers, so they can keep running while your code waits. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help subclassing Borg
On Sun, 08 May 2005 02:42:09 +1000, Steven D'Aprano wrote:
I'm thinking what I might need is a function that generates a Borg-like
class. So I would do something like:
Rabbit = MakeBorgClass()
# Rabbit is now a class implementing shared state
# all instances of Rabbit share the same state
Duck = MakeBorgClass()
# Duck is now a class implementing shared state
# all instances of Duck share the same state
# but instances of Duck do not share state with instances of Rabbit
Problem is, I haven't got the foggiest idea how to implement something
like that. Am I on the right track? Where do I go from here?
Bengt's answer is better than this track, but this question is worth
answering because it is so wonderfully easy in Python.
Remember class is an executable statement, not a declaration:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type help, copyright, credits or license for more information.
def makeBorg():
... class Borg(object):
... _shared_state = {}
... def __init__(self):
... self.__dict__ = self._shared_state
... return Borg
...
Duck = makeBorg()
Rabbit = makeBorg()
d = Duck()
d2 = Duck()
d.cover = fur
d2.cover
'fur'
r = Rabbit()
r.cover
Traceback (most recent call last):
File stdin, line 1, in ?
AttributeError: 'Borg' object has no attribute 'cover'
r.cover = feathers
d.cover
'fur'
r2 = Rabbit()
r2.cover
'feathers'
(I flipped around the fur and feathers, but don't feel like fixing it :-) )
Now, the problem with this and the reason why Bengt's is more likely
better is that each of these Borg classes is unrelated, so there's no
using issubclass or anything like that. You *could* hack around this, but
it's not worth it. (It is possible to dynamically choose the bases of a
class; you can't do it in the class statement itself, but you can do
something like:
def makeBorg(base = object):
class Borg(base):
etc.
but this is definitely not the best way to go. Still, as above, it does
have its place other times; I've used it to dynamically pick up whether
the user has certain modules installed and add support depending on the
environment. I often do this when I'm writing something currently embedded
in an app I'm writing, but may have use elsewhere outside of the
environment of the app, allowing me to write code that both takes full
advantage of the app environment, while not being completely tied to it.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: saving dialog variables
On Sat, 07 May 2005 13:24:34 +, jeff elkins wrote: Howdy, I've written a program that calls an imported dialog to gather some needed input. What's the common method for passing that data back to the caller? I've tried a 'return data' prior to self.Close() ... all that happens then is the dialog won't close. I'm sure this is obvious, but this newbie's stuck! Thanks, Jeff In general, the dialog is an instance of a class. Once the dialog closes, the window should be gone but the instance variable should still be around. Common practice is to put the relevant data in the dialog instance member for retrieval after closing. In certain cases, the method used to invoke the dialog will return the relevant value, but this is somewhat limiting. In even more rare cases, the dialog will be popped up by a function, giving no direct reference to the dialog at any point, and the value is returned by the function; this is generally limited to the Yes/No/Cancel style dialog or its simpler bretheren (OK/Cancel and OK). I'm assuming that last one is not the case. To be more directly helpful, we'd need more data, ideally a code snippet fully demonstrating the problem (i.e., a runnable program). But at a bare minimum, we'd need to know where this dialog came from. Tk? PyGTK? wxPython? Some curses library? MFC? -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: The `print' statement over Unicode
On Sat, 07 May 2005 12:10:46 -0400, Franois Pinard wrote: [Martin von Lwis] Franois Pinard wrote: Am I looking in the wrong places, or else, should not the standard documentation more handily explain such things? It should, but, alas, it doesn't. Contributions are welcome. My contributions are not that welcome. If they were, the core team would not try forcing me into using robots and bug trackers! :-) I'm not sure that the smiley completely de-fangs this comment. Have you every tried managing a project even a tenth the size of Python *without* those tools? If you had any idea of the kind of continuous, day-in, day-out *useless busywork* you were asking of the developers, merely to save you a minute or two on the one occasion you have something to contribute, you'd apologize for the incredibly unreasonable demand you are making from people giving you an amazing amount of free stuff. (You'd get a lot less of it, too; administration isn't coding, and excessive administration makes the coding even less fun and thus less likely to be done.) An apology would not be out of line, smiley or no. I've never administered anything the size of Python. I have, however, been up close and personal with a project that had about five developers full-time, and administering *that* without bug trackers would have been a nightmare. I can't even imagine trying to run Python by hand at least not that and getting useful work done too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie: saving dialog variables
On Sat, 07 May 2005 15:43:08 +, jeff elkins wrote: === import wx def create(parent): return vents(parent) [wxID_VENTS, wxID_VENTSEXITBUTTON, wxID_VENTSVENTTYPETEXT, [snip] ] = [wx.NewId() for _init_ctrls in range(14) ] class vents(wx.Dialog): def _init_ctrls(self, prnt): wx.Dialog.__init__(self, id=wxID_VENTS, name=u'prefs', parent=prnt, pos=wx.Point(418, 320), size=wx.Size(321, 285), style=wx.DEFAULT_DIALOG_STYLE, title=u'Ventilator Settings') self.SetClientSize(wx.Size(321, 285)) self.exitButton = wx.Button(id=wxID_VENTSEXITBUTTON, label=u'OK', name=u'exitButton', parent=self, pos=wx.Point(60, 250), size=wx.Size(85, 30), style=0) self.exitButton.Bind(wx.EVT_BUTTON, self.OnExitButtonButton, id=wxID_VENTSEXITBUTTON) self.venttypeText = wx.TextCtrl(id=wxID_VENTSVENTTYPETEXT, name=u'venttypeText', parent=self, pos=wx.Point(64, 24), size=wx.Size(144, 25), style=0, value=u'') [snip] def __init__(self, parent): self._init_ctrls(parent) # build an array of values entered in the dialog # return array to calling program def OnExitButtonButton(self, event): self.Close() == The dialog above is called by: def OnVentButtonButton(self, event): dlg = vents.vents(self) try: dlg.ShowModal() finally: dlg.Destroy() OK, I can't quite directly run this, but assuming you're trying to get the user to enter some text into the text control, you should be able to add print dlg.venttypeText.GetValue() to print what the user entered; this comes after the try: finally: (i.e., on the same indentation as dlg = vents.vents(self)). The dialog window is gone, but the widgets and such inside it should remain until it is garbage collected. (One of the keys to effective UI use is dissociating the screen representation from the widget data structure representation; certainly they are related but they are not identical, generally the widget data structure is around both before and after the actual display of the widget.) On an unrelated note, somehow, the dialog should indicate if it was cancelled or not; you'll need to consult the docs for that. It looks like you don't want the user to be able to cancel, but watch out for sneaky cancelling techniques; ESC might be automatically mapped to some sort of cancel by the wx.Dialog class, and the user might also be able to click on a close window button on the resulting dialog box, which may also get processed as a cancel. I don't think it'll affect your code in this particular case (it can sometimes), but it's bad UI; there should be a style that shows a window with no close button on it. (Default may be it, but I'd be surprised.) That style will probably also not do the default keyboard mapping, so it should take care of both problems. If you pull up the dialog and it has no close button and ESC does nothing, disregard this :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie : checking semantics
On Sat, 07 May 2005 15:05:20 -0700, LDD wrote: The fact that python doesn't check if the symbol AFunctionThatIsntDefined is defined, is really bad when you develop big pieces of code. You will never be sure that your code is free of this kind of dummy errors and testing every possible execution paths is nightmarish ! Your unsubstantiated claim flies in the face of many man-years of experience writing Python programs... and also has been discussed here so many times it's hardly possible to count them. Summary: We know better, from experience. Quote dogma until you're blue in the face, but nobody has managed to prove that large Python apps don't exist, nor have they been able to show they were harder to write than equivalent apps in more structured languages, which is also a tough sell since they were easier. To win this point, you need to produce evidence that doesn't exist. Why not try opening your mind to the possibility that the dogma is wrong? Points to ponder: http://www.mindview.net/WebLog/log-0025 http://www.artima.com/weblogs/viewpost.jsp?thread=4639 The other point worth making is that if you want a language that you already know, why not stick with it? Is there a way to force Python to check the definition of symbol ? Look up pychecker, but beyond that, no. It turns out such a thing is meaningless in the sense you are used to (static analysis), because a symbol may not have a referent until much later, and based on arbitrary code. Python is late-binding, unlike C/C++/Java and friends. I think that about summarizes the current state of the art on this point. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect a double's significant digits
On Fri, 06 May 2005 08:27:03 +0200, Fredrik Lundh wrote: Jeremy Bowers wrote: A step which will require him to tell the printing routine how many digits he wants printed. Not necessarily; consider the str() of a float in Python, especially given the significant digits aspect (it may be ill-defined, but I can think of several well-defined ways to mean that, where str() embodies one of them). The easiest way to tell how long the number will be when str prints it out is to simply ask it. and what language is str() implemented in? Who cares? It demonstrates the existence of a print routine that prints a variable number of characters. In C++, this may be harder, as your output software may insist on rendering everything directly, with no way to reach in and tell what it did. Imagine the standard IOStreams, without the ability to stream into a string. but you can stream into a string buffer, and you can use sprintf() from C++, so what's your point, besides stating that if things were harder, they would be harder? Giving the original poster the benefit of the doubt, I assumed he was dealing with some sort of screen library that would render something without telling him the size, that didn't use streams at all. If that library also implemented its own pretty print, string streams and everything else don't help; you need *that* library's pretty print. -- http://mail.python.org/mailman/listinfo/python-list
Re: Listening to changes in a C++ variable from python
On Fri, 06 May 2005 19:56:34 -0700, lamthierry wrote: Let's say I have the following source code in C++: // The following is in a .cpp file int val = 0; for ( int i = 0; i 10; i++ ) val = i; // Now I'm in a python GUI, glade or GTK Is it possible from the GUI side to listen to changes in the val variable? Once I notice a change in the variable, I will update a widget(for example a display progress bar from glade). Any advice or solutions? It is not possible to listen to something that is not emitting change notifications. Your variable val isn't talking. Some languages let you listen to every variable, but that is because behind the scenes it is emitting every variable change as an event. In C++, in keeping with its general philosophy, it is not going to be possible to listen to an int. You must either poll it, or wrap that int in something that *will* emit change messages in some fashion that satisfies you. Given the circumstance of updating a progress bar, I'd poll it about every quarter to half second. The correct answer changes depending on what you are doing with the info and the level of control you exert over the source C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect a double's significant digits
On Thu, 05 May 2005 18:42:17 +, Charles Krug wrote: On 5 May 2005 10:37:00 -0700, mrstephengross [EMAIL PROTECTED] wrote: Hi all... How can I find out the number of significant digits (to the right of the decimal place, that is) in a double? At least, I *think* that's what I'm asking for. For instance: 0.103 -- 3 0.0103 -- 4 0.00103 -- 5 0.000103 -- 6 0.103 -- 7 Thanks in advance! --Steve ([EMAIL PROTECTED]) I would say that each of these examples has three signficant figures. Each of them can be expressed as: 1.03e+n For any integer n. You beat me to it. Step one for mrstephengross is to *rigorously* define what he means by significant digits, then go from there. Since I think he mentioned something about predicting how much space it will take to print out, my suggestion is to run through whatever printing routines there are and get a string out, the measure the string, as anything else will likely be wrong. If that's not possible with the formatting library, you've already lost; you'll have to completely correctly re-implement the formatting library, and not only is that a major PITA, you almost never get it bug-for-bug right... -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect a double's significant digits
On Fri, 06 May 2005 02:44:43 +, Grant Edwards wrote: On 2005-05-05, Jeremy Bowers [EMAIL PROTECTED] wrote: Since I think he mentioned something about predicting how much space it will take to print out, my suggestion is to run through whatever printing routines there are and get a string out, A step which will require him to tell the printing routine how many digits he wants printed. Not necessarily; consider the str() of a float in Python, especially given the significant digits aspect (it may be ill-defined, but I can think of several well-defined ways to mean that, where str() embodies one of them). The easiest way to tell how long the number will be when str prints it out is to simply ask it. In C++, this may be harder, as your output software may insist on rendering everything directly, with no way to reach in and tell what it did. Imagine the standard IOStreams, without the ability to stream into a string. Now it's a lot harder to tell. So if you've got something smart like the default str() in Python, you may not be able to tell in advance what it is going to do, short of trying to manually reverse engineer it. I've tried that a few times, and in each instance, I can get 95-99%... but I never quite make it to 100%, usually because I find a bug somewhere and can't figure out how to characterize and replicate it. (The biggest of these so far was when I tried to reconstruct Tk's wrapping in a text widget, so I could tell how many screen lines the given piece of text I produced would consume, whereupon I discovered Tk didn't correctly wrap all Unicode characters... it correctly (as far as I could see) reported their widths, but happily let the characters run right off the right edge of the widget under certain circumstances I could never characterize without putting in even more effort than I cared to. The bugs aren't always *important*, one can imagine the opposite problem of wrapping a little too quickly, and it could be years before anyone notices if it's just a few pixels off in the right direction, but it'll still screw you up if you try to replicate it.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How to detect a double's significant digits
On Thu, 05 May 2005 20:08:46 -0700, Erik Max Francis wrote: Grant's point was that as significance is used in scientific studies, there's no way to answer the question without having the number in advance. My point was that the original poster never defined significance in that manner, and in the manner in which he seemed to be using the term, my comments made sense. Which is why the first thing I said was he needs to rigorously define what he means, and everything after that was predicated on the assumption he seemed to be looking at consumed screen space. -- http://mail.python.org/mailman/listinfo/python-list
Re: empty lists vs empty generators
On Wed, 04 May 2005 13:45:00 +, Leif K-Brooks wrote: Jeremy Bowers wrote: def __init__(self, generator): self.generator = generator You'll want to use iter(generator) there in order to handle reiterables. Can you expand that explanation a bit? I'm not certain what you mean. I'm just trusting what the user passes in; maybe the user should pass it iter(generator) when it's a reiterable? (Honest question.) What definition of re-iterable are you using? (A quick google for Python reiterabile just turns up some Python dev list entries from 2003.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How to write this regular expression?
On Wed, 04 May 2005 20:24:51 +0800, could ildg wrote:
Thank you.
I just learned how to use re, so I want to find a way to settle it by
using re. I know that split it into pieces will do it quickly.
I'll say this; you have two problems, splitting out the numbers and
verifying their conformance to some validity rule.
I strongly recommend treating those two problems separately. While I'm not
willing to guarantee that an RE can't be written for something like ([A
number A]_[A number B] such that A B) in the general case, it won't be
anywhere near as clean or as easy to follow if you just write an RE to
extract the numbers, then verify the constraints in conventional Python.
In that case, if you know in advance that the numbers are guaranteed to be
in that format, I'd just use the regular expression \d+, and the
findall method of the compile expression:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type help, copyright, credits or license for more information.
import re
m = re.compile(\d+)
m.findall(344mmm555m)
['344', '555', '']
If you're checking general matching of the parameters you've given, I'd
feel no shame in checking the string against r^(_\d+){1,3}$ with .match
and then using the above to get the numbers, if you prefer that. (Note
that I believe .match implies the initial ^, but I tend to write it
anyways as a good habit. Explicit better than implicit and all that.)
(I just tried to capture the three numbers by adding a parentheses set
around the \d+ but it only gives me the first. I've never tried that
before; is there a way to get it to give me all of them? I don't think so,
so two REs may be required after all.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: empty lists vs empty generators
On Wed, 04 May 2005 20:33:31 +, Leif K-Brooks wrote: With the EmptyGeneratorDetector class as you defined it, lists will fail: EmptyGeneratorDetector([]) Traceback (most recent call last): File stdin, line 1, in ? File stdin, line 15, in __init__ AttributeError: 'list' object has no attribute 'next' Of course, the class is labeled as an empty generator detector, not an empty iterable detector, so it's doing what it says it will, but a little bit of extra generalism can't hurt. OK, thanks, now I see what you mean. I was worried that you might be referring to an iterator type that returned something other than itself when you called iter on it, which I thought wasn't legal. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to write this regular expression?
On Thu, 05 May 2005 09:30:21 +0800, could ildg wrote:
Jeremy Bowers wrote:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12) [GCC 3.4.3 (Gentoo Linux
3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2 Type help, copyright,
credits or license for more information.
import re
m = re.compile(\d+)
m.findall(344mmm555m)
['344', '555', '']
(I just tried to capture the three numbers by adding a parentheses set
around the \d+ but it only gives me the first. I've never tried that
before; is there a way to get it to give me all of them? I don't think
so, so two REs may be required after all.)
You can capture each number by using group, each group can have a name.
I think you missed out on what I meant:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type help, copyright, credits or license for more information.
import re
m = re.compile(r((?Pname\d+)_){1,3})
match = m.match(12_34_56_)
match.groups(name)
('56_', '56')
Can you also get 12 34 out of it? (Interesting, as the non-named groups
give you the *first* match)
I guess I've never wanted this because I usually end up using findall
instead, but I could still see this being useful... parsing a function
call, for instance, and getting a tuple of the arguments instead of all of
them at once to be broken up later could be useful.
--
http://mail.python.org/mailman/listinfo/python-list
Re: compare two voices
On Mon, 02 May 2005 13:58:07 -0500, phil wrote: You didn't indicate how deep you want to get into the code yourself. I am gonna step way out of my mathematical depth here I mean no disrespect, but this is the last accurate statement you made. I wouldn't say this, except that if the original poster tries to follow your advice, they'd be wasting a lot of time, so in I feel obligated to speak out. If it were that easy, phoneme recognition would have been a solved problem in the 70s. It is quite a bit harder than just waving Matlab at the problem. Based on the subsequent posts by the original poster, giving me a better feel of their skill level, I would estimate that in order to get to where they want to be, they are a minimum of nine years of solid work away from solving the problem, assuming no degree in computer science. (Such a degree would equip them better to know how hard the problem is, though you could get an undergrad degree without acquiring the requisite knowledge; with an undergrad degree in hand, subtract two years.) I am completely, 100% serious on that time estimate, and that's just to get you to the point where you *may* be able to solve the problem. Anyone who tells you it's less either has a solution in hand that you can use (good, but nobody has chimed up yet, except one guy to say it's really, really hard, he knows because he tried, so I'm not holding my breath), or has no clue what they are talking about. (We are often trained to be unthinkingly encouraging, but it is a net good to discourage someone from wasting significant amounts of time, oblivious to the fact they are unlikely to succeed. If the original poster wishes to dedicate that much time to the project, I would be happy to tell them how they can begin the process of learning what they need to learn, as long as they are aware of what they are starting.) -- http://mail.python.org/mailman/listinfo/python-list
Re: compare two voices (Jeremy Bowers)
On Mon, 02 May 2005 16:37:19 -0500, phil wrote: I will defend one statement though. I have yet to see anything which Python would not make a good wrapper for. Some of the OpenGL pygame stuff is very cool. Alright, you got me :-) I got excessively broad. -- http://mail.python.org/mailman/listinfo/python-list
Re: empty lists vs empty generators
On Mon, 02 May 2005 16:14:57 -0700, Brian Roberts wrote: Q1: Is there a better or alternate way to handle this? Q2: Is there a way that handles both lists and generators, so I don't have to worry about which one I've got? Are you in control of your generators? You could put a method on them that tells if there is anything in them by manually implementing the .next() call. The other thing you could do is a generator wrapper that can tell for you, but you'll lose some performance: class EmptyGeneratorDetector(object): Provides a method you can call to detect an empty generator. You should probably name this class something shorter. Check if the generator is empty after construction by looking at the isEmpty property. def __init__(self, generator): self.generator = generator self.isEmpty = False self.givenFirst = False try: self.firstItem = generator.next() except StopIteration: self.isEmpty = True def next(self): if self.isEmpty: raise StopIteration if not self.givenFirst: self.givenFirst = True return self.firstItem else: return self.generator.next() def __iter__(self): return self In action: Python 2.3.5 (#1, Mar 3 2005, 17:32:12) [GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2 Type help, copyright, credits or license for more information. from genwrap import * def emptyGenerator(): ... raise StopIteration ... yield None ... def nonEmptyGenerator(): ... yield 1 ... yield 2 ... yield 3 ... e = emptyGenerator() n = nonEmptyGenerator() E = EmptyGeneratorDetector(e) N = EmptyGeneratorDetector(n) E.isEmpty True N.isEmpty False for i in E: ... print i ... for i in N: ... print i ... 1 2 3 It is tested as much as you see it above :-) (I recall a lengthy discussion of the best way to create an empty iterator a while back, and that was not the winner. But it will do for now.) -- http://mail.python.org/mailman/listinfo/python-list
Re: compare two voices
On Sat, 30 Apr 2005 20:00:57 -0700, Qiangning Hong wrote: I want to make an app to help students study foreign language. I want the following function in it: The student reads a piece of text to the microphone. The software records it and compares it to the wave-file pre-recorded by the teacher, and gives out a score to indicate the similarity between them. This function will help the students pronounce properly, I think. Do you have any idea what it takes to compare two voices in a *meaningful* fashion? This is a serious question. I can't guarantee there is no app to help with this, but if it does exist, it either costs a lot of money, or will be almost impossible to use for what you want (boiling two voice samples down to a speaker-independent single similarity number... the mind boggles at the possible number of ways of defining that). Quite possibly both. If you *do* know something about the math, which, by the way, is graduate level+, then you'd do better to go look at the open source voice recognition systems and ask on those mailing lists. No matter how you slice it, this is not a Python problem, this is an intense voice recognition algorithm problem that would make a good PhD thesis. I have no idea if it has already been done and you will likely get much better help from such a community where people might know that. I am aware of the CMU Sphinx project, which should get you started Googling. Good luck; it's a great idea, but if somebody somewhere hasn't already done it, it's an extremely tough one. (Theoretically, it's probably not a horrid problem, but my intuition leads me to believe that turning it into a *useful product*, that corresponds to what humans would say is similar, will probably be a practical nightmare. Plus it'll be highly language dependent; a similarity algorithm for Chinese probably won't work very well for English and vice versa. All this, and you *could* just play the two sounds back to the human and let their brain try to understand it... ;-) ) Waiting for the message pointing to the Sourceforge project that implemented this three years ago... -- http://mail.python.org/mailman/listinfo/python-list
Re: OOP
On Thu, 28 Apr 2005 10:34:44 -0700, demon_slayer2839 wrote: Hey yall, I'm new to Python and I love it. Now I can get most of the topics covered with the Python tutorials I've read but the one thats just stumping me is Object Orientation. I can't get the grasp of it. Does anyone know of a good resource that could possibly put things in focus for me? Thanks. The biggest problem with understanding Object Orientation is that it is only a net gain, even when using something as nice as Python, when you pass the trivial. If you're looking at provided examples of OO that fits on a screen or two and going And so what...?, I'd actually consider that a sign of comprehension, not a bad thing. (No sarcasm.) It only goes past And so what...? when you get into larger programs. One example that exists in the Python library and has a lot of code available on line is the urllib2 library. (Unfortunately, that is something of a complicated bit of code and you're almost better off just listening to what I'm going to say here than actually looking at the code :-) )It uses an OO pattern called the template pattern, where you bundle as much code as possible that can be used generally into a superclass, and inherit and specialize when you need to do something specific. When you want to send an HTTP request, and do something useful with the results, you create your own request subclass. As a result of using it, the superclass does all of it's stuff, in this case making the connection and basic parsing of the results, so you don't have to. The superclass then calls into the sub-class's overridden methods, based on what happened with the request. For instance, if you are writing an RSS retriever and the retrieval results in a 302 code, Moved Permanently, the superclass will call self.error_302(), and the RSS reader can then update its personal database of RSS file locations. OO consists structurally of the code+data combination; OO consists *practically* of each of these little techniques, like I gave in the previous paragraph, adding together and making things easy. None of them are *impossible* with non-OO code, merely harder to write, but the cumulative easing effect is quite significant. You're probably closer to understanding the theory than you think; now you just need to use it for a while, with an active, open mind probing for ways to make your programming life easier. Only that will bring deeper understanding, or maybe reading other's code if you're dedicated. You might also look online for some of the Design Patterns, which aren't worth worshiping but provide a concise description of some of the other things that OO makes easier than the alternatives. (You may also be interested in this essay I wrote: http://www.jerf.org/writings/bowersLaw.html One of the problems OO faced in general, especially the late 80s and most of the 90s, was prematurely jumping to dogma before there was adequate community experience to formulate a *good* dogma; even today there are a lot of OO experts who would take extensive exception to both this post and that essay, even though I'm pretty sure that facts and experience are on my side :-) . The old dogma lives on, even as many communities like Python, Ruby, and the Testing Methodology folk are formulating better ones. The reality of OO is that it is a rich and highly varied *family* of techniques, which may also not be helping if you try to learn from multiple sources; that essay tries to explore the common thread behind all of those techniques, and explain why it is the common thread.) -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I parse this ? regexp ? [slighly OT]
On Thu, 28 Apr 2005 20:53:14 -0400, Peter Hansen wrote: The re docs clearly say this is not the case: ''' [] Used to indicate a set of characters. Characters can be listed individually, or a range of characters can be indicated by giving two characters and separating them by a -. Special characters are not active inside sets. ''' Note the last sentence in the above quotation... -Peter Aren't regexes /fun/? Also from that passage, Simon, note the - right in front of [-\[\]0-9,. ], another one that's tripped me up more than once. Wh! Some people, when confronted with a problem, think ``I know, I'll use regular expressions.'' Now they have two problems. - jwz http://www.jwz.org/hacks/marginal.html -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I parse this ? regexp ?
On Wed, 27 Apr 2005 07:56:11 -0700, [EMAIL PROTECTED] wrote:
Hello all,
I have this line of numbers:
04242005 18:20:42-0.02, 271.1748608, [-4.119873046875,
3.4332275390625, 105.062255859375], [0.093780517578125, 0.041015625,
-0.960662841796875], [0.01556396484375, 0.01220703125, 0.01068115234375]
repeated several times in a text file and I would like each element to be
part of a vector. how do I do this ? I am not very capable in using regexp
as you can see.
I think, based on the responses you've gotten so far, that perhaps you
aren't being clear enough.
Some starter questions:
* Is that all on one line in your file?
* Are there ever variable numbers of the [] fields?
* What do you mean by vectors?
If the line format is stable (no variation in numbers), and especially if
that is all one line, given that you are not familiar with regexp I
wouldn't muck about with it. (For me, I'd still say it's borderline if I
would go with that.) Instead, follow along in the following and it'll
probably help, though as I don't precisely know what you're asking I can't
give a complete solution:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type help, copyright, credits or license for more information.
x = 04242005 18:20:42-0.02, 271.1748608, [-4.119873046875, 3.4332275390
625, 105.062255859375], [0.093780517578125, 0.041015625, -0.960662841796875], [0
.01556396484375, 0.01220703125, 0.01068115234375]
x.split(',', 2)
['04242005 18:20:42-0.02', ' 271.1748608', ' [-4.119873046875, 3.43322753906
25, 105.062255859375], [0.093780517578125, 0.041015625, -0.960662841796875], [0.
01556396484375, 0.01220703125, 0.01068115234375]']
splitted = x.split(',', 2)
splitted[2]
' [-4.119873046875, 3.4332275390625, 105.062255859375], [0.093780517578125, 0.04
1015625, -0.960662841796875], [0.01556396484375, 0.01220703125, 0.01068115234375
]'
import re
safetyChecker = re.compile(r^[-\[\]0-9,. ]*$)
if safetyChecker.match(splitted[2]):
... eval(splitted[2], {}, {})
...
([-4.119873046875, 3.4332275390625, 105.062255859375], [0.093780517578125,
0.041015625, -0.960662841796875], [0.01556396484375, 0.01220703125,
0.01068115234375])
splitted[0].split()
['04242005', '18:20:42-0.02']
splitted[0].split()[1].split('-')
['18:20:42', '0.02']
I'd like to STRONGLY EMPHASIZE that there is danger in using eval as it
is very dangerous if you can't trust the source; *any* python code will
be run. That is why I am extra paranoid and double-check that the
expression only has the characters listed in that simple regex in it.
(Anyone who can construct a malicious string out of those characters will
get my sincere admiration.) You may do as you please, of course, but I
believe it is not helpful to suggest security holes on comp.lang.python
:-) The coincidence of that part of your data, which is also the most
challenging to parse, exactly matching Python syntax is too much to pass
up.
This should give you some good ideas; if you post more detailed questions
we can probably be of more help.
--
http://mail.python.org/mailman/listinfo/python-list
Re: tkinter text width
On Wed, 27 Apr 2005 10:52:14 -0700, James Stroud wrote: This is more or less what I would like, but I would also like to probe the Text to see how many characters it thinks it can display within the container window. I am formatting text dynamically and so I rely on the width. I am not after the built in wrap option, it does not do what I want. But, say if wrap were turned on, it would be good to know how many characters the Text would wrap at. I have extensive experience with trying to get text containers to do this. It is not easy. You have two choices: 1. Give up. You can't tell anyhow if you're using a proportional font. 2. Use a fixed-width font and manually wrap. (It's pretty easy then, you can ask the font for how wide any char is and do the math from there.) I have 70 line function that tries to replicate the Tk wrapping algorithm in the proportional text case, and it *still* doesn't work. For one thing, I actually found some bugs in the wrapping code (if a Unicode character gets into just the right position, it can actually run off the right end of the text widget, even if the widget is being wrapped), so completely matching the layout seems infeasible. I would strongly, strongly suggest finding another way to do what you are trying to do. I have blown many, many hours on this problem, and I found no simple logic. The edge cases kill you; while Tk is consistent (same text, same wrap every time), sometimes it wraps a word if it goes up to the edge, sometimes if it's one pixel off, damned if I can find a pattern (probably has something to do with trying to space the letters out, kerning or one of its simpler friends), and it probably changes periodically anyhow... and note based on this I can't even guarantee #2 above, if you get unlucky. Basically, I'm pretty sure you can't do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: tkinter text width
On Wed, 27 Apr 2005 12:52:21 -0700, James Stroud wrote: Thank you to everybody helping me. I think I am almost there... On Wednesday 27 April 2005 12:10 pm, so sayeth Jeremy Bowers: 2. Use a fixed-width font and manually wrap. (It's pretty easy then, you can ask the font for how wide any char is and do the math from there.) How might I query the size of a fixed-width font in pixles? It appears that the width of the font in points does not correlate with its width in pixels based on some simple expriments I have done. Using cget(font) on the Text gives back a string with the point size. Ah, in that case you want the measure attribute of the font object. http://www.pythonware.com/library/tkinter/introduction/x4671-methods.htm [snip some things to worry about] Basically, I'm pretty sure you can't do this. My setup is not very complicated, so I don't think I have to worry about kerning, unicode, etc.. I am using a fixed width font (courier) only, and only one size and am also quite comfortable with giving away several pixels at the end of a line for rounding errors and will filter for a limited alphabet consisting only of the numbers, the captial letters, and the space. I think I can do this given these limitations. Sounds like it. What I did was set up unit test that threw random snippets at the text widget, and compared how many lines my code thought the widget should have, vs. what the widget claimed to have. This is how I discovered that some unicode was wrapped incorrectly. You can get what the widget claims to have by asking it for the geometric position of the last character with the bbox method of the Text widget. This is, however, probably not the answer you are looking for, because you only get a bounding box if the text is currently visible on the screen. This makes it fairly difficult to use to ask the widget *how far* off the screen the text is. If it were that easy I would have said so earlier :-) But you may find that useful too, as you cobble together a solution. -- http://mail.python.org/mailman/listinfo/python-list
Re: creating very small types
On Wed, 27 Apr 2005 22:17:07 +0200, andrea wrote: I was thinking to code the huffman algorithm and trying to compress something with it, but I've got a problem. How can I represent for example a char with only 3 bits?? I had a look to the compression modules but I can't understand them much... Thank you very much Any good link would be appreciated of course :) I think the answer to this question very much depends on why you want to do this. Easy and fast are pretty opposed in this particular domain in Python (IMHO anyways, it's an easy bit-bashing language but it's slow for that), and you're in one of the rare domains where it matters. The answers strongly vary if you're trying to create something performant, or just for your learning purposes. Or homework purposes... ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
On Tue, 26 Apr 2005 02:12:07 -0500, Mike Meyer wrote: Right. But that shouldn't be hard to do. Let genexp stand for a a generator expression/list comprehension without any brackets on it at all. Then [genexp] is the syntax to expand the list. [(genexp)] is the syntax to create a list of one element - a generator object. foo(genexp) will do the right thing. In other words, everything as it is today, only with different implementations under the hood. :-) Rolling back around to the original point, I don't see any reason to ban [x for x in thing], changing current practice, when it is so easy to keep it. [(x for x in thing)] is also current practice (perhaps bad style in some sense, but definately possible in 2.4), and I don't think there is a good reason to change that, either. -- http://mail.python.org/mailman/listinfo/python-list
Re: delete will assure file is deleted?
On Tue, 26 Apr 2005 03:40:16 -0700, [EMAIL PROTECTED] wrote: Hello Mike, I have to know this topic otherwise my program has to check whether the file / files are already deleted and this is a little bit messy. I would be fairly confident in asserting that assuming the file is there, you have permissions, etc., basically that the call succeeds, that the file will be gone. os.remove, as the module name implies, tells the OS to do something. I would consider an OS that returned from a remove call, but still let you access that file, highly broken. You may be concerned that the OS may not write the fact that the file is deleted to the disk right away. This is very, very possible; OSs have been doing that for a while. If, for some reason, this is a major concern that the system might suddenly lose power and the file may not be truly deleted, you will need to either shut off this feature (it is called write-behind caching, and shutting it off, or indeed even having the feature at all, is OS-dependent), or get a UPS so that the machine has time to shut down gracefully. HOWEVER... the only time this is a problem is if you are truly concerned about the power spontaneously shutting off. The kernel of your operating system, if indeed it does write-behind caching at all, will make it look to all programs on the system (not just your own) that the file is deleted; and thus, in every sense that matters barring spectacular power failure, it is. So I say, ever if you've heard of write-behind caching and you are perhaps worried about it, you do not need to be; it is intended to be fully transparent to you, and indeed, short of directly asking the OS whether the feature is on, there should be no practical way of figuring out whether it is on at all. All it means is significantly better performance to you programs if they do things like delete a lot of files at once; you don't need to worry that they might still be there even after the command is done. This reply somewhat longer than needed for the purposes of education :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: regex over files
On Tue, 26 Apr 2005 19:32:29 +0100, Robin Becker wrote: Skip Montanaro wrote: Robin So we avoid dirty page writes etc etc. However, I still think I Robin could get away with a small window into the file which would be Robin more efficient. It's hard to imagine how sliding a small window onto a file within Python would be more efficient than the operating system's paging system. ;-) Skip well it might be if I only want to scan forward through the file (think lexical analysis). Most lexical analyzers use a buffer and produce a stream of tokens ie a compressed version of the input. There are problems crossing buffers etc, but we never normally need the whole file in memory. I think you might have a misunderstanding here. mmap puts a file into *virtual* memory. It does *not* read the whole thing into physical memory; if it did, there would be no purpose to mmap support in the OS in the first place, as a thin wrapper around existing file calls would work. If the lexical analyzer reads the whole file into memory then we need more pages. The mmap thing might help as we need only read pages (for a lexical scanner). The read-write status of the pages is not why mmap is an advantage; the advantage is that the OS naturally and transparent is taking care of loading just the portions you want, and intelligently discarding them when you are done (more intelligently than you could, even in theory, since it can take advantage of knowing the entire state of the system, your program can't). In other words, as Skip was trying to tell you, mmap *already does* what you are saying might be better, and it does it better than you can, even in theory, from inside a process (as the OS will not reveal to you the data structures it has that you would need to match that performance). As you try to understand mmap, make sure your mental model can take into account the fact that it is easy and quite common to mmap a file several times larger than your physical memory, and it does not even *try* to read the whole thing in at any given time. You may benefit from reviewing/studying the difference between virtual memory and physical memory. -- http://mail.python.org/mailman/listinfo/python-list
Re: delete will assure file is deleted?
On Tue, 26 Apr 2005 21:24:30 +0200, andreas wrote:
On Tue, Apr 26, 2005 at 03:13:20PM -0400, Jeremy Bowers wrote:
On Tue, 26 Apr 2005 03:40:16 -0700, [EMAIL PROTECTED] wrote:
Hello Mike,
I have to know this topic otherwise my program has to check whether the
file / files are already deleted and this is a little bit messy.
I would be fairly confident in asserting that assuming the file is there,
you have permissions, etc., basically that the call succeeds, that the
file will be gone.
Not exactly. The system call is called remove not by accident. It's not
called delete. So for example if you have a file with multiple names (so
called
hard links) the file will not be gone after os.remove('file')
This gets into another distinction that I didn't want to get into, given
that my message was heavy enough as it is.
But I would say, that even if file_a and file_b are both (hard) linked
to the same file, and I remove file_a, I am perfectly justified in
saying that file_a is gone, deleted, removed, what have you. The file,
the thing we called file_a, is no longer accessible. That some operating
systems separate file from contents and thus that I can get at the
contents in some other way doesn't really make that statement untrue;
file_a is still gone. file deleted hasn't meant file contents
eliminated from the disk entirely, well, as far as I know, *ever*;
certainly there were undelete operations in DOS, and that's as far back as
I can attest to personally, but I know that undeletes could be done
before then, too. In fact one must search in computing for anything to
ever truly be *eliminated*; in more than just file systems, we
de-allocate, re-allocate for something else, and just overwrite. That's a
pervasive pattern.
--
http://mail.python.org/mailman/listinfo/python-list
Re: regex over files
On Tue, 26 Apr 2005 20:54:53 +, Robin Becker wrote: Skip Montanaro wrote: ... If I mmap() a file, it's not slurped into main memory immediately, though as you pointed out, it's charged to my process's virtual memory. As I access bits of the file's contents, it will page in only what's necessary. If I mmap() a huge file, then print out a few bytes from the middle, only the page containing the interesting bytes is actually copied into physical memory. my simple rather stupid experiment indicates that windows mmap at least will reserve 25Mb of paged file for a linear scan through a 25Mb file. I probably only need 4096b to scan. That's a lot less than even the page table requirement. This isn't rocket science just an old style observation. Are you trying to claim Skip is wrong, or what? There's little value in saying that by mapping a file of 25MB into VM pages, you've increased your allocated paged file space by 25MB. That's effectively tautological. If you are trying to claim Skip is wrong, you *do not understand* what you are talking about. Talk less, listen and study more. (This is my best guess, as like I said, observing that allocating things increases the number of things that are allocated isn't worth posting so my thought is you think you are proving something. If you really are just posting something tautological, my apologies and disregard this paragraph but, well, it's certainly not out of line at this point.) -- http://mail.python.org/mailman/listinfo/python-list
Re: schedule a monthly ftp event
On Tue, 26 Apr 2005 15:15:35 -0700, willitfw wrote: Greetings, I am looking for some guidance on a script. My goals are: 1) have this script run automatically through a time set schedule. 2) verify if a file is updated on an ftp site (usually on the 15th of the month). 3) If the updated file exists, ftp it to local drive. 4) e-mail other users when the file has been updated on the local drive. Operating system? comp.lang.python can help you with the other stuff, but the scheduling is OS-dependent. (Which isn't to say you won't get help, but it is, technically, off topic.) On UNIX, use some cron varient, Windows has some sort of Scheduler built in but I've never done anything with it but turn it off, and I have no clue about Mac, though perhaps it has cron too in OSX. -- http://mail.python.org/mailman/listinfo/python-list
Re: delete will assure file is deleted?
On Tue, 26 Apr 2005 21:24:06 -0500, Mike Meyer wrote: Jeremy Bowers [EMAIL PROTECTED] writes: On Tue, 26 Apr 2005 03:40:16 -0700, [EMAIL PROTECTED] wrote: os.remove, as the module name implies, tells the OS to do something. I would consider an OS that returned from a remove call, but still let you access that file, highly broken. Um - not if you have permission to read the file, but don't have permission to remove it. You snipped: assuming the file is there, you have permissions, etc., basically that the call succeeds, First paragraph. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
On Sun, 24 Apr 2005 22:59:12 -0700, Robert Kern wrote: Never. If you really need a list list(x*x for x in xrange(10)) Sadly, we can't remove list comprehensions until 3.0. Why remove them? Instead, we have these things called comprehensions (which, now that I say that, seems a rather odd name), and you can control whether they result in a list or a generator with () or []. I don't see why they need to be removed. Lists are already a special case of the only one way to do it principle ([] vs. list()), and pragmatically I don't see any reason to remove them here; it doesn't add comprehensibility, leaving them in doesn't significantly affect the mental size of the code (the *comprehension* is the hard part, the final form should be relatively simple), it's not worth breaking that code. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
On Mon, 25 Apr 2005 16:48:46 -0400, Bill Mill wrote: On 25 Apr 2005 23:33:48 +0300, Ville Vainio [EMAIL PROTECTED] wrote: Still, list comprehensions should be implemented in terms of genexps to get rid of the LC variable that is visible outside the scope of the LC. +1 . I think that we should still have the form [genexp] , but without the dangling variable, and implemented with generator expressions. It seems to me that it is inconsistent if I can do list(genexp) but not [genexp] , since they are so similar. Once that happens, we can tell people who ask the OP's question that [genexp] is just another way to spell list(genexp), and he should use it if he wants the entire list constructed in memory. This is what I meant. Robert Kern says the implementations really differ, but I submit that is an accident of the order they were created in, not a fundamental constraint. list(genexp) works today and does almost exactly the same thing, minus an optimization or two that people are working on generalizing anyways, which is the right approach. I doubt that Python 3.0 would have two radically different implementations; they'll just have the genexp implementation, and an optimization for list creation if the list creation can know the size in advance, regardless of where it came from. Jeremy should be relatively simple), it's not worth breaking that Jeremy code. Well, the code that relies on the dangling variable deserves to break. Agreed. This is not what I meant and I agree with it too. Breaking code depending on variable leaking is one thing; breaking all code that uses list comprehensions is quite another. Just because 3.0 is going to break a lot of code anyhow doesn't mean we should be *gratuitous* about it! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
On Mon, 25 Apr 2005 23:26:56 +, John Bokma wrote: Mike Meyer wrote: John Bokma [EMAIL PROTECTED] writes: Nobody ever changed their mind as a result of a 20-thread endless reply-fest. As usual, the posters aren't about to admit anything, and none of the bystanders are reading any more. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's do list comprehensions do that generator expressions don't?
On Mon, 25 Apr 2005 23:00:57 -0500, Mike Meyer wrote: Why do we have to wait for Python 3.0 for this? Couldn't list comprehensions and generator expression be unified without breaking existing code that didn't deserve to be broken? We don't; my mentioning 3.0 was just in reference to a previous comment. In fact it'll probably happen sooner than then, I just have no direct knowledge. (I know some people were talking about creating iterators that know how many things they contain, which is the critical optimization, but I don't know if that's gotten anywhere; I don't track the dev list as it is too much traffic for my already strained email client :-) ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Variables
On Sat, 23 Apr 2005 22:45:14 -0400, Richard Blackwood wrote: Indeed, this language is math. My friend says that foo is a constant and necessarily not a variable. If I had written foo = raw_input(), he would say that foo is a variable. Which is perfectly fine except that he insists that since programming came from math, the concept of variable is necessarily the identical. The concept? *snort* Your friend knows not of what he speaks. Ask him if parallel lines cross. Then ask him if he has any right to get snotty about terminology like that. If he hasn't got far enough into math to understand why that question is relevant, then he hasn't got far enough into math to opine on what a variable is, anyhow. (By the way, if he says no, and not it depends on your axiom choice, the same is true.) (By math, are we talking *real* math like number theory or set theory, something involving proofs, or high-school algebra that deals in numbers and mere arithmetic? I rather suspect the latter, in which case you may tell your friend y'all are so far out of your league you can't even tell how far out you are. Nobody who has studied number theory or alternate geometries or anything like real math could have this conversation, unless they *really* missed the point of, well, everything they've done up to that point...) -- http://mail.python.org/mailman/listinfo/python-list
Python Imaging Library and PyGTK - color image path?
I have an image in the Python Image Library. I'm trying to get it into PyGTK in color. Is there any way to do this cross-platform, preferably without writing to anything to the disk? PIL apparently can't write XPMs. GTK will only take XPMs, that I can see. Therein lies the rub. I can ship over monochrome bitmaps via XBM, but I'd rather be able to ship over full color. (Use case, in case it matters: I am trying to embed a graphic into a text widget. This is going fine. Because I want the text widget to be able use different size text, and no one image can look right with everything from 8pt to 40pt text (all reasonable possibilities), I load a large image in from the disk and scale it down as needed; the images are designed to scale well and later I can make multiple source images if that is desirable. But I can't figure out how to get the scaled image into GTK. This surprises me.) If there's an easy Google search, it has eluded me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Imaging Library and PyGTK - color image path?
On Fri, 22 Apr 2005 22:43:13 -0400, Jeremy Bowers wrote: (Use case, in case it matters: I am trying to embed a graphic into a text widget. This is going fine. Because I want the text widget to be able use different size text, and no one image can look right with everything from 8pt to 40pt text (all reasonable possibilities), I load a large image in from the disk and scale it down as needed; the images are designed to scale well and later I can make multiple source images if that is desirable. But I can't figure out how to get the scaled image into GTK. This surprises me.) As usual, posting for help after poking around for a long while guarantees you'll figure it out in the next few minutes. You need to create GDK pixbufs, which can be resized and scaled and stuff. There is definitely some room for confusion here with GTK Images, GDK Images, GTK pixbufs, and GDK pixbufs -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Imaging Library and PyGTK - color image path?
On Sat, 23 Apr 2005 10:20:29 +0200, Fredrik Lundh wrote: which discusses draw_rgb_image and friends, and says that if you can convert your PIL image to a pixel data string or buffer object, you could use them to display the image. here's some code that seems to do exactly that: http://www.mail-archive.com/pygtk@daa.com.au/msg07167.html (but maybe this is some kind of stupid a bitmap isn't a pixmap isn't an image thing? if so, I suggest getting a modern windowing system ;-) A varient; I was missing the gdk.pixbuf because I assumed that because there was a gtk.pixbuf that I knew about, that I had all relevant data. Were that the only pixbuf, that would be an atrocity. (Particularly odd for GTK, the *Gimp* windowing toolkit.) (It of course figures that was the google search; I think I tried everything but that; python imaging library pygtk isn't anywhere near as helpful, for instance.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or PHP?
On Sat, 23 Apr 2005 20:13:24 +0200, Mage wrote: Avoid them is easy with set_type($value,integer) for integer values and correct escaping for strings. Avoiding buffer overflows in C is easy, as long as you check the buffers each time. The *existence* of a technique to avoid problems is not in question. The problem is when the language makes it easier to *not* do the checks than to do the checks. Any look at the real world shows that that pattern causes trouble, and that clearly, the mere *existence* of a way to not get in trouble is not sufficient in the general case. Despite the fact that all you have to do to avoid cutting your finger off with a saw is not stick your finger in the saw, most people, even carpentry professionals, are going to want to use finger-guards and other safety equipment. A programmer turning down such security protection (without another good reason, which does happen), is being like the guy too macho to use the finger guard; stupidity induced by arrogance, not some one no longer using training wheels. Using PHP and futzing with SQL directly is probably not a good enough reason, as surely PHP has safer libraries available. (If not, my opinion of PHP goes down another notch.) Data binding with something like SQLObject makes it *easier* to be secure than insecure; barring an out-and-out bug in SQLObject (given the nature of the requisite bug, it is extremely unlikely to have survived this long), a programmer must go *way* out of their way to introduce the SQL injection attacks that so plague PHP projects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Supercomputer and encryption and compression @ rate of 96%
On Thu, 14 Apr 2005 17:44:56 +0200, Fredrik Lundh wrote: Will McGugan wrote: Muchas gracias. Although there may be a bug. I compressed my Evanescence albumn, but after decompression it became the complete works of Charles strange. the algorithm should be reversible. sounds like an operating system bug. what system are you using? /F After I compressed my OS (on the other machine) with your code, none, apparently. -- http://mail.python.org/mailman/listinfo/python-list
Re: semicolons
On Tue, 12 Apr 2005 00:14:03 +0200, Mage wrote: Hello, I amafraid of I will stop using semicolons in other languages after one or two months of python. However I see that python simply ignores the semicolons atd the end of the lines. What's your advice? I don't want to write full-of-typo php scripts but I see the logic of the python syntax too. Sorry, there's no easy answer for this. In your own Python code, you can include extraneous semi-colons, but if you intend to every distribute it, nobody is going to like working with that. -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sun, 10 Apr 2005 13:57:26 +0200, Diez B. Roggisch wrote: Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Can you show me some working, in-use example for that? I _seriously_ doubt that the process of rearranging and tuning the layout can be done faster in the text-world than with a good designer like qt-designer. But I'm all ears for better solutions. Regrettably, no. I have them but they are all unsharable, either because the real owner would consider them proprietary, or because they are an unreleased and at the moment unfinished product I can't give the code out for. But I can help some. Part of the problem is the incredible cognitive disconnect between the layout system of design and the system I'm advocating. You're looking at your designer and saying something like, well, if I want to re-order these two options, it's three drags, even less if there's an 'exchange' option, how can anything possibly be any easier? (At least, that's my guess.) But that is not where the advantage lies. One of the things I can't show you at the moment is actually written as a web application using Javascript and mod_perl. It's a bog-standard GUI app that edits databases, from the surface. SOP for the forms designer approach is to create a form for each thing that will be edited; in this case in HTML, but that's not particularly different and you can get form editors for that, too, if you try. But even now, we have at least 20 different types of things to edit, and the full power of databases is at play here; we have foreign keys that may have an arbitrary number of certain things (customers may have an arbitrary number of phone numbers, for instance; in practice of course you won't have 20, but they may have home, the may have home + work, the may have work + fax, etc.), and a customer's address may actually be in an Address table, rather than directly in their record. Add up all the little pieces and at the moment we've got around 100 different types of things that might need editing, many of which can have arbitrary links to other things. (Some of these 100 things are just link tables, SQL tables that link an ID in one table to an ID in another for many-to-many relationships and these will not directly be edited, but still there's a lot of things in play here.) We could try to create a form for each one, and in fact earlier versions of the system did just that. But that solution sucked, for all of the reasons I typically rant against these solutions; they rapidly got out of sync with the database schema, a bug fix in one was a bug fix in no others (copy and paste code tends to run rampant in this situation, though technically that's just a tendency, not a requirement), and any but the most critical enhancements are out of the question because they only affect a small part of the system. So, instead, with this new system (note I wasn't involved with the old system), I do everything with metadata. (Credit where credit is due, the other programmer was starting to do some of this, though he couldn't quite take it down to the interface and there are some things I had to add later.) Every thing (class) has a description of what it's made out of, and what type each of those things are. When I go to edit an instance, the Javascript pulls down that description, and a description of the instance (and all of its associated sub-instances), and instead *generates* a form to edit the object based on what it is made of. Right now, I'm emulating the old two col approach, labels on the left, values on the right, but I'll be changing that later. For now, though, that makes it easy (and like I said, as nice as forms are, having to do that many they bailed out and went with a standard design). And since I'm putting these things in by hand, I can also create custom widget types and use them. (For that, I'm using my XBLinJS library, so you can actually think of the HTML widgets as having capabilities much like Tkinter widgets, in that I can subclass from them and make them do domain-specific things just like Tk.) Integer value types get integer text boxes; these do not allow you to type anything but numbers. Floating point is the same way, but adds the . (although only one). All numeric fields do math within themselves, which is something that should have been standard for a decade now but programmers had to actually do something special in their forms to get it; I get it for the same price as anything else, once I wrote the code. (By that I mean, type 1+4 in and it will resolve itself to 5.) That's one of the reasons I rant about this; there is *so much* functionality like that that ought to be standard because done correctly it's trivial to plunk the right text widget subclass down if you're generating the screen, but form designers make this a lot of extra work.
Re: workaround for generating gui tools
On Sun, 10 Apr 2005 13:02:27 -0700, Ken Godee wrote: The original poster was just asking for an example of how to sub class his code generated form into his program for easy future updates, a VERY STANDARD way of doing it. I recognize your sarcasm, and I recognize the poor attitude it shows, but underneath it you do have a point. Continuing the (still IMHO very good) OO vs. procedural metaphor, the problem is that posting a trivial example of a dynamic interface, even were I to take the time to create one for you for free, would meet with exactly the same response that posting an OO snippet of some reasonable newsgroup size would receive from someone skeptical of OO. Well, heck, I can do that all in a procedural program, and it would be a little shorter, too! I am *particularly* not inclined to post a trivial example because it would do nothing to blunt your skepticism, or your sarcasm, and regardless, people who are genuinely curious simply need to try it for themselves. The advantages only start kicking in with large programs. But I do recall a book with similar themes, though I do not endorse it whole-heartedly: Software Development On A Leash, which also gives you sample code for his particular framework. http://www.apress.com/book/bookDisplay.html?bID=29 My opinion of this book is like my opinion of XP: Every serious programmer ought to be exposed to the ideas contained in it (even if not by exposure to this book or the actual XP writings), and ought to give them serious thought, but 100% acceptance is not necessary. To address your sarcasm directly, there's 456 pages of examples in professionally written prose and real code samples, which I don't entirely agree with but they do serve to show the point, available for the price of $39.95. I consider my obligation to you discharged on this point; if you prefer sarcasm to investing anything into your personal development, that's your problem, not mine. (If this were a private email, I would have just deleted it, but the underlying criticisms, even if uncivilly phrased, bore answering.) Even though you probably won't adopt this guys framework, if you're paid anything at all for programming you'll recover the $40 in no time with the ideas in that book. -- http://mail.python.org/mailman/listinfo/python-list
Re: workaround for generating gui tools
On Sat, 09 Apr 2005 19:59:18 +0200, Diez B. Roggisch wrote: why use data files when you have an extremely powerful programming language in your toolbox? the advantage of building UI's in Python is that you can quickly create domain specific UI languages, and use them to generate the interfaces for you. UI editors may be useful for trivial applications, but if you're doing complex stuff, you sure want domain- specific abstractions. Python gives you that, XML files don't. If you do some creative rearranging of widgets and play around with different layouts and geometry managers, a good gui-designer becomes very useful. Domain-specific abstractions do that *faster* than GUI designers, not slower. And better, too, since every iteration tends to be fully functional and not just a let's see what this looks like prototype. Heck, switch 'em out dynamically based on what day of the week it is and how the user feels today. Let's see your GUI-designer do that. And if you're not used to doing it that way, you'll be *stunned* at how much stuff tends to factor out and get easily re-used. An approach that has more data to work with (some idea of what things are doing and what they are for) will beat an approach with less data (thing at row 4, col 2 or, worst case, thing at 233,144) any day. GUI designers are like the regexs in the famous jwz quote: Some people, when confronted with a problem, think 'I know, I'll use a GUI designer'. Now they have two problems. Both have a niche in the quick fix department, both are typically over-used, but overall regexs are the more useful of the two; at least there are cases where they are the undisputed right answer (like defining tokens in a language parser). Generally, over the first couple of weeks of a project, the domain-specific language writer may seem to be behind the GUI designer cranking out screen after screen of templated GUI widgets, but after a couple of weeks the domain-specific language user will pull into the lead and never give it up, and will be a lot happier to boot. -- http://mail.python.org/mailman/listinfo/python-list
Re: args attribute of Exception objects
On Fri, 08 Apr 2005 09:32:37 +, Sbastien de Menten wrote: Hi, When I need to make sense of a python exception, I often need to parse the string exception in order to retrieve the data. What exactly are you doing with this info? (Every time I started to do this, I found a better way. Perhaps one of them will apply for you.) (As a general comment, I'd point out that you don't have to check the entire error message; checking for a descriptive substring, while still not safe, is at least safe*r*.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Can dictionary values access their keys?
On Fri, 08 Apr 2005 10:33:53 -0600, Matthew Thorley wrote: I must say I am *very* suprised that python does not have a way to look up what key is pointing to a given object--without scanning the whole list that is. Assuming fairly optimal data structures, nothing is free. Python chooses not to have bi-directional dicts built in. A good reason for this is that it is easy to build a two-way dict out of two one-way dicts, and there's no obvious way to build a built-in two-way dict that is any more efficient than that. Python chooses to allow all objects potentially to be dict keys, which has overhead vs. an implementation such as that in Perl that only allows strings. Either of those is tolerable ultimately, though I do prefer Python's approach as I key things on objects all the time. It's all a matter of tradeoffs. Building all the dicts as two-way in memory consumes twice the memory and twice the processor power for a lot of situations where the second direction isn't used, so *on average* that's not a good tradeoff. Even though Python doesn't have a built-in way, it is easy to write your own class that interoperates transparently, and there are many ones you can grab off the 'net, even given to you in this thread :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python sleep doesn't work right in a loop?
On Wed, 06 Apr 2005 12:49:51 -0700, ritterhaus wrote: Nope. Does't work. Running Python 2.3.4 on Debian, Linux kernel 2.6. This is actually test code for a larger project... # flash the selected wx.TextControl for flasher in range(4): self.textField.SetBackgroundColour(255, 0, 0) time.sleep(0.8) self.textField.SetBackgroundColour(255, 255, 223) time.sleep(0.8) Even when I add an explicit call to repaint the TextCtrl between each sleep, things appear to be 'queued' until after the loop is fnished. Very bizarre. GUIs don't like time.sleep. All of them come with some sort of fire a timing event in X milliseconds and call this handler. Use that instead. I believe wx's is the wxTimer class, and the wxFutureCall class looks promising. If you want to maintain the same basic calling structure, start playing games with generators; you can write the same function with yield, and then call .next() on an iterator every time the timeout triggers. Best of both worlds. -- http://mail.python.org/mailman/listinfo/python-list
Re: testing -- what to do for testing code with behaviour dependant upon which files exist?
On Mon, 04 Apr 2005 17:02:20 -0400, Brian van den Broek wrote: Jeremy suggested using a directory name akin to C:\onlyanidiotwouldhavethisdirecotrynameonadrive. That is what I had settled on before I posted. Somehow it feels unhappy and inelegant. But, I'm a bit less uncomfortable with it seeing that others have done so, too. To be clear, I would actually suggest onlyanidiotwouldhavethisdirecotrynameonadrive... note the lack of C:\, which would be platform specific, as would any other root specification. Take advantage of the fact that every system I know of makes relative directories easy, and also note you can work out what directory the current file is in with a combination of __file__ and os.getcwd() (and that while that won't work if someone changes the working directory, that's bad form and IIRC breaks some other things in Python as well, so don't do that). Making it a relative directory may make it look just as bad, but it is in some sense somewhat less inelegant; at that point, if someone is creating that directory in the test directory of your app, they're just fooling with you, and you don't really have to worry about people who maliciously make your unit tests fail under most circumstances... :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest vs py.test?
On Mon, 04 Apr 2005 22:50:35 +, John J. Lee wrote: What I don't understand about py.test (and trying it out seems unlikely to answer this) is why it uses the assert statement. unittest used to do that, too, but then it was pointed out that that breaks when python -O is used, so unittest switched to self.assert_ c. Does py.test have some way around that? Don't use -O because it doesn't do anything significant? Is this an issue in practice? (Honest question.) If -O did something interesting I might use it, but I don't think it does. -- http://mail.python.org/mailman/listinfo/python-list
Re: testing -- what to do for testing code with behaviour dependant upon which files exist?
On Sat, 02 Apr 2005 15:30:13 -0500, Brian van den Broek wrote: So, how does one handle such cases with tests? When I had a similar situation, I created a directory for testing that was in a known state, and tested on that. If you can test based on a relative directory, that should work OK. Non-existant paths shouldn't be too hard to come up with; hardcoding a constant relative dir of THISDIRECTORYCANTPOSSIBLYEXISTANDIFITDOESYOURENUTS ought to do OK. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda: the Ultimate Design Flaw
On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote: Daniel Silva wrote: Shriram Krishnamurthi has just announced the following elsewhere; it might be of interest to c.l.s, c.l.f, and c.l.p: http://list.cs.brown.edu/pipermail/plt-scheme/2005-April/008382.html April Fool's Day again, eh? Yes and no. In the Python community, we're taking all of that pretty seriously. The scheme community may not seriously be thinking of getting rid of those things, but it's hardly impossible that some people think it might be better off without it. -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest vs py.test?
On Fri, 01 Apr 2005 16:42:30 +, Raymond Hettinger wrote: FWIW, the evolution of py.test is to also work seemlessly with existing tests from the unittest module. Is this true now, or is this planned? I read(/skimmed) the docs for py.test when you linked to the project, but I don't recall seeing that. Certainly some of the features made me drool but I have an investment in unittest. If I can relatively easily port them over, I'd love to use py.test. (I don't care about a small per-file change, it'd probably be one I can automate anyhow. But I can't afford to re-write every test.) I didn't see anything like this in the docs, but I may have missed it. That'd be cool. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorater inside a function? Is there a way?
On Fri, 01 Apr 2005 18:30:56 +, Ron_Adam wrote: I'm trying to figure out how to test function arguments by adding a decorator. The rest of your message then goes on to vividly demonstrate why decorators make for a poor test technique. Is this an April Fools gag? If so, it's not a very good one as it's quite in line with the sort of question I've seen many times before. I have a hammer, how do I use it to inflate my tire? Assuming you're serious, why not use one of the many testing technologies actually designed for it, and tap into the associated body of knowledge on how to accomplish various tasks? Start with what you're trying to do, then work on how to do it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorater inside a function? Is there a way?
On Fri, 01 Apr 2005 19:56:55 +, Ron_Adam wrote:
On Fri, 01 Apr 2005 13:47:06 -0500, Jeremy Bowers [EMAIL PROTECTED]
wrote:
Is this an April Fools gag? If so, it's not a very good one as it's quite
in line with the sort of question I've seen many times before. I have
a hammer, how do I use it to inflate my tire?
Not an April fools gag, I'm just new to decorators and google brings
up lots of discussions from the past on how they may be implemented in
the future, but not much in actually how they work or how to use them.
OK, just checking :-)
A decorator is completely equivalent in principle to
def function():
pass
function = decorator(function)
That's a simplified form; decorators can themselves be an expression which
returns a callable that can be applied to a function and the rule for
applying several in sequence work as you'd expect (pipelining earlier
results into later ones, making for a great Obfuscated Python entry or
two based on the function name misdirection trick), but this simplified
form captures the essense, which is what I think you're looking for. In
particular, it's just syntax sugar, not a special feature.
I'm trying to understand the use's, limits, and possibilities of
decorators.
It just occurred to me that wrapping the contents of a function vs
wrapping the function it's self, could be useful.
Decorators, literally, can only wrap functions. You can write a wrapper
then that does something to the arguments, which people sometimes do, but
you can't directly wrap the arguments.
Note, having shown you how decorators work, you can manually apply the
decorator yourself:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type help, copyright, credits or license for more information.
import string
string._join = string.join
def joinWrap(*args, **kwargs):
... print args, kwargs
... return My Wrapper, string._join(*args, **kwargs)
...
string.join = joinWrap
string.join([1,2,3], |)
My Wrapper (['1', '2', '3'], '|') {}
'1|2|3'
So, whatever it is you are trying can do can still be done without the
decorator syntax, and *this* is not unheard of, though managing the
references correctly can be tricky the first few times if you're not used
to it. (Note the replaced function (join in this example) can go anywhere
the wrapper can get at it, I just stick it back in the original module for
simplicity.) It's not the first thing I reach for, in fact in all my
testing code I don't think I ever do this, but it is in the toolbox.
Do this instead of abusing the decorator syntax; you could write a
decorator that tries to figure out if it's being run in a testing
environment and conditionally affects the function, but that's probably a
bad idea.
Feeling-like-I-owed-you-an-answer-after-the-april-fool-accusation-ly yrs,
Jeremy Bowers
:-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: try / except not worknig correctly
On Sat, 12 Mar 2005 17:06:17 -0800, '@'.join([..join(['fred','dixon']),..join(['gmail','com'])]) wrote: I'd also suggest validInput = ABCDEFGHIJKL # and there are more clever ways to do this, # but this will do myInput = raw_input( .join(validInput) + ?) if len(myInput) != 1: # do whatever pass if myInput not in validInput: raise ValueError(Input not in legal input: + validInput) Obviously not a drop-in replacement for your code, but ought to clean it up a little. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pseudocode in the wikipedia
On Fri, 01 Apr 2005 16:02:53 -0500, Gabriel Cooper wrote: Ron_Adam wrote: To me := could mean to create a copy of an object... or should it be =: ? Or how about :=) to mean is equal and :=( to mean it's not. Then there is ;=), to indicate 'True', and ':=O' to indicate 'False' Not to mention (_ | _) for asserts! Your ass is your identity function. Python 2.3.5 (#1, Mar 3 2005, 17:32:12) [GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2 Type help, copyright, credits or license for more information. 25 25 (_ | _) 25 There's clearly some interesting biometrics research to be done here, although there is a well-known ass-capturing attack based on readily commercially available machines from Xerox that might make it hard to make an ass-based identity system resistant to attacks. -- http://mail.python.org/mailman/listinfo/python-list
Re: How To Do It Faster?!?
On Thu, 31 Mar 2005 13:38:34 +0200, andrea.gavana wrote: Hello NG, in my application, I use os.walk() to walk on a BIG directory. I need to retrieve the files, in each sub-directory, that are owned by a particular user. Noting that I am on Windows (2000 or XP), this is what I do: You should *try* directly retrieving the relevant information from the OS, instead of spawning a dir process. I have no idea how to do that and it will probably require the win32 extensions for Python. After that, you're done. Odds are you'll be disk bound. In fact, you may get no gain if Windows is optimized enough that the process you describe below is *still* disk-bound. Your only hope then is two things: * Poke around in the Windows API for a function that does what you want, and hope it can do it faster due to being in the kernel. * Somehow work this out to be lazy so it tries to grab what the user is looking at, instead of absolutely everything. Whether or not this will work depends on your application. If you post more information about how you are using this data, I can try to help you. (I've had some experience in this domain, but what is good heavily depends on what you are doing. For instance, if you're batch processing a whole bunch of records after the user gave a bulk command, there's not much you can do. But if they're looking at something in a Windows Explorer-like tree view, there's a lot you can do to improve responsiveness, even if you can't speed up the process overall.) -- http://mail.python.org/mailman/listinfo/python-list
Re: decorator syntax polling suggestion
On Fri, 13 Aug 2004 16:49:53 +1000, Anthony Baxter wrote: The people who hate pie-decorators post a _lot_ - most people seem to either not care, or else post once or twice and then disappear. I just posted on another mailing list about how posting the same message, over and over, is fundamentally offensive; it implies the belief, from whatever the source, that the poster needs to show you the light and if they just keep pounding on it, they'll eventually blast through your ignorance. People who internalize this will not look loud in a debate, so it is important to not just look at volume. (My call: Hated it at first, waded through the arguments and alternatives, now agree with the syntax as is.) -- http://mail.python.org/mailman/listinfo/python-list
Re: decorator syntax polling suggestion
On Fri, 01 Apr 2005 16:52:52 -0500, Jeremy Bowers wrote: Oops, sorry, some send later messages I thought were gone got sent. Sorry. Didn't mean to revive dead threads. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with splitting
On Fri, 01 Apr 2005 14:20:51 -0800, RickMuller wrote: I'm trying to split a string into pieces on whitespace, but I want to save the whitespace characters rather than discarding them. For example, I want to split the string '12' into ['1','','2']. I was certain that there was a way to do this using the standard string functions, but I just spent some time poring over the documentation without finding anything. importPython 2.3.5 (#1, Mar 3 2005, 17:32:12) [GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2 Type help, copyright, credits or license for more information. import re whitespaceSplitter = re.compile((\w+)) whitespaceSplitter.split(1 2 3 \t\n5) ['', '1', ' ', '2', ' ', '3', ' \t\n', '5', ''] whitespaceSplitter.split( 1 2 3 \t\n5 ) [' ', '1', ' ', '2', ' ', '3', ' \t\n', '5', ' '] Note the null strings at the beginning and end if there are no instances of the split RE at the beginning or end. Pondering the second invocation should show why they are there, though darned if I can think of a good way to put it into words. -- http://mail.python.org/mailman/listinfo/python-list
Re: that is it is not it (logic in Python)
On Fri, 01 Apr 2005 22:01:25 +, F. Petitjean wrote: Le Fri, 1 Apr 2005 13:39:47 -0500, Terry Reedy a crit : This is equivalent to '(that is it) and (it is not it)' which is clearly false. False # What ? Reread the ref manual on chained comparison operators. And see the date of the post :-) that is it isn't it ? Nope, nothing to do with it. Read the ref manual on chained comparision operators. http://www.python.org/doc/2.4/ref/comparisons.html#l2h-430 For proof, run the given code in the original post. It's not faked in the slightest, and the manual holds the key to understanding. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with splitting
On Fri, 01 Apr 2005 18:01:49 -0500, Brian Beck wrote:
py from itertools import groupby
py [''.join(g) for k, g in groupby(' test ing ', lambda x: x.isspace())]
[' ', 'test', ' ', 'ing', ' ']
I tried replacing the lambda thing with an attrgetter, but apparently my
understanding of that isn't perfect... it groups by the identify of the
bound method instead of calling it...
Unfortunately, as you pointed out, it is slower:
python timeit.py -s
import re; x = 'a ab c' * 1000; whitespaceSplitter = re.compile('(\w+)')
whitespaceSplitter.split(x)
100 loops, best of 3: 9.47 msec per loop
python timeit.py -s
from itertools import groupby; x = 'a ab c' * 1000;
[''.join(g) for k, g in groupby(x, lambda y: y.isspace())]
10 loops, best of 3: 65.8 msec per loop
(tried to break it up to be easier to read)
But I like yours much better theoretically. It's also a pretty good demo
of groupby.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How To Do It Faster?!?
On Sat, 02 Apr 2005 01:00:34 +0200, andrea_gavana wrote: Hello Jeremy NG, ... I hope to have been clearer this time... I really welcome all your suggestions. Yes, clearer, though I still don't know what you're *doing* with that data :-) Here's an idea to sort of come at the problem from a different angle. Can you run something on the file server itself, and use RPC to access it? The reason I mention this is a lot of UNIXes have an API to detect file changes live; for instance, google python fam. It would be easy to hook something up to scan the files at startup and maintain your totals live, and then use one of the many extremely easy Python RPC mechanisms to request the data as the user wants it, which would most likely come back at network speeds (fast). This would be orders of magnitude faster, and no scanning system could compete with it. -- http://mail.python.org/mailman/listinfo/python-list
FAM and Python? (was Re: How To Do It Faster?!?)
On Sat, 02 Apr 2005 02:02:31 +0200, andrea_gavana wrote: Hello Jeremy NG, Every user of thsi big directory works on big studies regarding oil fields. Knowing the amount of data (and number of files) we have to deal with (produced by simulators, visualization tools, and so on) and knowing that users are usually lazy in doing clean up of unused/old files, this is a way for one of us to fast scan all the directories and identify which files belong to him. Having them in an organized, size-sorted wxPython list, the user can decide if he want to delete some files (that almost surely he forgot even that they exist...) or not. It is easy as a button click (retrieve the data--delete the files). Got it. A good idea! Here's an idea to sort of come at the problem from a different angle. Can you run something on the file server itself, and use RPC to access it? I don't even know what is RPC... I have to look at it. RPC stands for remote procedure call. The idea is that you do something that looks like a normal function call, except it happens on a remote server. Complexity varies widely. Given your situation, and if running something on the UNIX server is a possibility, I'd recommend downloading and playing with Pyro; it is Python specific, so I think it would be the best thing for you, being powerful, well integrated with Python, and easy to use. Then, on your client machine in Windows, ultimately you'd make some sort of call to your server like fileList = server.getFileList(user) and you'd get the file list for that user, returning whatever you want for your app; a list of tuples, objects, whatever you want. Pyro will add no constraints to your app. I am not sure if my new explanation fits with your last information... as above, I didn't even know about fam... I've read a little, but probably I am too newbie to see a link between it and my scope. Do you think it exists? It would be nice to have something that tracks the file status on all the file system, but probably is a LOT of work wrt what my app should be able to do. Maybe, maybe not. I've never used FAM. Perhaps someone who has can chime in about the ease of use; I've changed the subject to try to attract such a person. It also depends on if FAM works on your UNIX. My point is that you can do one scan at startup (can't avoid this), but then as the file system monitor tells you that a change has occurred, you update your data structures to account for the change. That way, your data is always in sync. (For safety's sake, you might set the server to terminate itself and re-start every night.) Since it's always in sync, you can send this data back instead of scanning the file system. At this point, my suggestion would be to consider whether you want to spend the effort to speed it up like this, which is something only you (and presumably your managers) are in a position to know, given that you have an existing tool (at least, you seem to speak like you have a functional tool). If you do, then I'd take some time and work a bit with Pyro and FAM, and *then* re-evaluate where you stand. By then you'll probably be able to ask better questions, too, and like I said above, perhaps someone will share their experiences with FAM. Good luck, and have fun; seriously, that's important here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
On Sat, 26 Mar 2005 15:42:03 +, Tim Tyler wrote: I very much favour the smalltalk-inspired idea of keeping the actual language as small as is reasonably possible. I wonder if there are any promising new kids on the dynamic scripting-language block that I haven't heard about yet - i.e. things not on: http://dmoz.org/Computers/Programming/Languages/Scripting/Object-Oriented/ http://dmoz.org/Computers/Programming/Languages/Object-Oriented/Prototype-based/ Personally, I'm holding off on any more exploration of dynamic languages until they all settle on a single VM that they all can run on. The problem that a new language faces is that it will have a sucky library, and I use things like Tk or other graphical toolkits for *everything*. Once you can write a new language and still pull in the entire Python library (and, ideally, the entire Ruby, Perl, and who knows what else library), then I think it will be more interesting for me to search out other languages. My next language to learn will probably be C#. (On Mono, though.) -- http://mail.python.org/mailman/listinfo/python-list
Re: html tags and python
On Sat, 26 Mar 2005 18:07:01 -0800, EP wrote:
Then... about the time you start to try to build a real application with
JavaScript, it will start to drive you mad... and you will have a new,
greater affection for Python.
Actually, if you dig into it really hard, it's not bad. In fact of all the
languages I know, Javascript is probably the closest to Python circa 1.5.2
that I can think of. Not identical, and it doesn't have *any* of the later
nice things in Python (metaclasses, descriptors, list comprehensions,
etc.), the OO can be clumsy (though it is fairly functional), and there
are inconveniences that I really wish I could make go away, but it's not
too bad.
(The worst being that
for (var something in someArray) {}
gives you the *indices* of the array, not the values, so the next line is
almost always
var theActualStinkingValue = someArray[something];
.)
The DOM is clumsy, but for any given browser not to bad. The *differences*
in the DOMs from browser to browser are what kill you. And of course, no
real libraries.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Grouping code by indentation - feature or ******?
On Fri, 25 Mar 2005 11:31:33 -0800, James Stroud wrote: Now, what happened to the whitespace idea here? This code seems very unpythonic. I think : is great for slices and lamda where things go on one line, but to require it to specify the start of a block of code seems a little perlish. It depends. Are you looking to eliminate punctuation entirely, or strike a proper balance? Yes, it's a loaded question, but yes, it reflects reality. Go look at a few hundred lines of Python code. Strip the colons off of the end. Barring the if bleh: something() one-liners*, it starts to look like a giant run on sentence to me. That's the native English speaker in me, but still, the historic trend was to add some punctuation as soon as technology made it non-burdensome. You don't *need* vowels in written text, either, but I see you and your language using them. Readability counts. ... practicality beats purity. Dropping the colon would just be getting silly. *: Where the colon *is* necessary; you need *something* to delimit the condition from the action, we've discussed this in the past but here's an example: if (a)(b)(c) can be if (a):(b)(c) if (a)(b):(c) ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggestions for a Java programmer
On Thu, 24 Mar 2005 00:22:09 -0800, Ray wrote: Can you point me to Python for Java Programmers resources? I found one blog, but that only touched the tip of the iceberg, I feel. I know that as I use Python more and read more books and read how experienced Python programmers code, eventually I'll find it out. But I'd like to expedite that process if possible. What are your suggestions? Also don't be afraid to post a this ought to be easier post here. While it will most like rapidly turn into an unofficial contest for regulars to post the niftiest solution, the first few messages will be helpful, and you'll leave Google fodder for future people with that concern. And besides, the contest might teach you several other things as well. Basically, everybody wins :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: setattr inside a module
On Wed, 23 Mar 2005 11:35:34 +0100, kramb64 wrote: I'm trying to use setattr inside a module. From outside a module it's easy: import spam name=hello value=1 setattr(spam, name, value) But if I want to do this inside the module spam itself, what I've to pass to setattr as first argument? Thanks a lot for your time. Marco. As others point out, sys.modules[__name__] I find myself doing this more and more, not less, as I get further into Python; autogenerating many similar functions, pulling constants from an external source, stuff like that, usually very meta and every instinct says its the right thing to do. Maybe we should have a __module__ attribute that is a reference to the current module? sys.modules[__name__] is a little obtuse. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
On Sat, 19 Mar 2005 20:07:40 -0800, Kay Schluehr wrote: It is bad OO design, George. I want to be a bit more become more specific on this and provide an example: Having thought about this for a bit, I agree it is a powerful counter-argument and in many other languages I'd consider this a total win. But this is Python, and frankly, I've overridden dict more than once and violated the Liskov substitution principle without thinking twice. (Once, oh yes, but not twice.) Of course, all the code was under my control then. I think the tipping point for me depends on how the interfaces in Python are going to be implemented, which I haven't dug into. If the dict class gets an interface definition, can I subclass from dict and cancel (or some other term) the interface I inherited? If so, then this might still be OK, although if interfaces aren't going to confuse newbies enough, wait 'till we try to explain that their code is blowing up because they forgot to cancel their interface, and they can't *really* pass their subclass in to something expecting a dict interface. If you *can't* cancel or downgrade the interface, then I'd say this argument is still good; dict should be kept minimal and this should go in a subclass. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing the Keyboard output
On Sun, 20 Mar 2005 19:30:05 +, Abdul Hafiz al-Muslim wrote: Hi, I am new to Python and still learning. I am looking for a way to change the keyboard output within Tkinter - for example, say I press p and I want to come out as t. Could anyone point me in the right direction? I'm pretty certain this is not possible in the general case. One of my persistent pet peeves with GUI toolkits is that it is not possible to insert your own arbitrary events into the toolkit and get the toolkit to do *exactly* what it would have done if it had received that event. While I believe Tk has a post event method, it only posts user events, I do not think you can post system events. This would completely change the testability and programmability of all GUI toolkits, radically improving them for agile development... but that's another rant. Meanwhile, you've got two options, depending on what you are trying to do, what platform you are on, and whether you control the target system. You could actually re-map the keyboard, which all major OSs support, although that may be too drastic. You could register two event handlers to the same handling function, so that both p and t go to the same place. Finally, if you're working with a Text widget, and you want a t to come out when users press p, what you do is capture the p event (either by registering p or Key), insert a t at the INSERT point, move the INSERT event forward if you have to, and then cancel the key event by returning break. Basically, you are implementing the keypress handler manually. (To fully emulate the keypress, consider if you want to emulate the behavior where a keypress destroys the highlighted range, in which case you need to look at SEL too.) This is a pain, and there are a lot of cases to cover, but it can be done. -- http://mail.python.org/mailman/listinfo/python-list
Limerick (was: Re: Text-to-speech)
On Sun, 20 Mar 2005 16:18:14 -0500, Steve Holden wrote: Since it's PyCon week, I will offer a prize of $100 to the best (in my opinion) limerick about Python posted to this list (with a Cc: to [EMAIL PROTECTED]) before midday on Friday. The prize money will be my own, so there are no other rules. I will post my judgment when the PyCon nonsense has died down a little, but the winner will be read before the entire PyCon audience. Get to it! regards Steve Practicality beats purity, Errors should never pass silently. Sparse is better than dense, Flat is better than nest, Beautiful is better than ugly. No cc because A: I'm not really serious and B: Tim Peters would have to get some credit for that. :-) Probably ought to add a C: While I think that does mostly rhyme, it is pretty loose; not much source material to work with. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
On Wed, 16 Mar 2005 16:35:57 -0600, Mike Meyer wrote: The real problem is that newbies won't know which features are meta features best left to experts, and which features are ok for everyday programmers to use. We recently saw a thread (couldn't find it in google groups) where some was trying to write decorators that would add a variable to a functions local namespace. When they actually stated the problem, it was a problem trivially solved by inheriting behavior, and that OO solution was what the OP finally adopted. But most of a week got wasted chasing a solution that should never have been investigated in the first place. This isn't a new problem, and I'm not convinced it even makes it worse. We (speaking broadly) have had to ask No, what is it you are trying to *do*? for a long time. Whether the 'newbie' is reaching for decorators to add a variable, trying to use lambdas to print, or trying to use XML-RPC to make calls to local functions, the newbie who is going to ask How do I do this wrong thing? isn't going to be affected either way by the addition or removal of metaclasses, or much of anything else. Is this arguable? Yes, absolutely, and I think none of us have the data to prove this one way or the other. But a priori it is not obvious that adding a few more possible mistakes to the already effectively infinite set of them is necessary going to trap anybody who wasn't going to get trapped on something else. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
On Wed, 16 Mar 2005 17:28:51 -0800, James Stroud wrote: On Wednesday 16 March 2005 04:45 pm, Robert Kern wrote: This would be very unambiguous. Not entirely. Then, the purity would manifest itself the naked comma being an empty tuple. Think about the zen of: , Is that a tuple or grit on my monitor? :-) OK, OK, I'll give up on the commas. Maybe we should just use dollar signs :? No, using symbols like that is bad. Clearly we need a new parser constant, THE_ZERO_LENGTH_EMPTY_TUPLE. We will, of course, have to forbid assigning any other name to that constant (more language changes) so that people don't start creating their own inconsistent name... *especially* shorter ones. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jython Phone Interview Advice
On Tue, 15 Mar 2005 03:21:19 -0800, George Jempty wrote:
I'm noticing that Javascript's array/hash literal syntax is EXACTLY the
same as that for Python lists/dictionaries.
No it isn't, quite.
Two differences of note, one literally syntax and one technically not but
you probably still want to know about it.
First, Javascript objects can only use strings for keys, anything used as
a key will be converted to a string. Try this in your browser and you'll
see what I mean... the instance of the class I define (let's not get
into prototyping issues here :-) ) has its string value used as the key,
not the object:
javascript:function a(){}; a.prototype.toString = function () {return
'q';}; b = new a(); c = {}; c[b] = 1; alert(c['q'])
(All one line, if your browser objects to the newline.)
The other is the syntax point: The strings you use in {} expressions to
denote keys are used literally, they are not resolved. Thus, in the above
I *had* to write
c = {};
c[b] = 1;
Because had I written
c = {b: 1}
I would have ended up with an object where c['b'] == 1; Javascript does
not resolve the expression, 'cause it isn't one.
(That said, certain reserved words like class and such do have to be
quoted, which means the safe bet is to quote them all, which leads to
Javascript objects that look identical to Python dicts. But
{1+2: moo}
will end up different in each language.}
steve_irwinDanger danger danger!/steve_irwin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python becoming less Lisp-like
On Tue, 15 Mar 2005 03:21:48 -0800, Paul Boddie wrote: Well, I've been using Python for almost ten years, and I've managed to deliberately ignore descriptors and metaclasses quite successfully. I get the impression that descriptors in particular are a detail of the low-level implementation that get a disproportionate level of coverage because of the hack value they can provide (albeit with seemingly inappropriate application to certain problem areas). I kept playing with descriptors, and tearing them out of production code, but I finally figured out how to think of them, I think. You want to create a descriptor for a type of property() that you keep using over and over again. If it's a one-off, use a property and be done with it. If you find yourself writing the same property over and over again, having access to the descriptor itself lets you factor it out so you can write it Once and Only Once (IMHO the highest of all programming laws^H^H^H^H^H rules of thumb). I went a long time before I came up with a use case for that, but now I have one where I want an attribute to fire an event in a particular manner every time it is changed. Rather than write a read function and a write function for each attribute (or try to hack it with closures or other arcane enchantments), it was easy to pack it up as a descriptor. It's a little too large to just copy and paste, but the upshot is that I can use it just like this: class Whatever(object): name = EmitOnChange(nameChange, _name) and that will fire a nameChange event into my event system every time someone modifies name, and the real value is stored in _name. (Obviously, I use it more than this once in the real code.) This may not be the best way to look at it from the C point of view, but I think it's a good way to look at it from the Python point of view. It probably is pretty rare that you need this, but it's there. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to delete the close button (the X on the right most corner of the window) on a window
On Sun, 13 Mar 2005 09:25:43 -0800, jrlen balane wrote: i am working on an MDIParentFrame and MDIChildFrame. Now, what i want to do is make the ChildFrame not that easy to close by removing the close button (the X on the right most corner of the window) if this is possible... how am i going to do this? Why is this a Python question? (This isn't just a snide comment; it matters what you're doing to know what to say. And of course, if you're not using Python, you're in the wrong place...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Add Properties to Instances?
On Sat, 12 Mar 2005 09:48:42 -0800, Martin Miller wrote: I'm trying to create some read-only instance specific properties, but the following attempt didn't work: I'm going to echo Steven's comment: What's the situation in which you think you want different properties for different instances of the same class? Another thought would be a custom __setattr__ and a bit of support: Python 2.3.5 (#1, Mar 3 2005, 17:32:12) [GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2 Type help, copyright, credits or license for more information. import sets class ReadOnlyAttributes(object): ... def __init__(self): ... self.__dict__['_readOnly'] = sets.Set() ... def addReadOnly(self, key, value): ... setattr(self, key, value) ... self._readOnly.add(key) ... def __setattr__(self, key, value): ... if key in self._readOnly: ... raise AttributeError(can't set attribute) ... self.__dict__[key] = value ... r = ReadOnlyAttributes() r.a = 22 r.a 22 r.a = 23 r.a 23 r.addReadOnly(a, 22) r.a 22 r.a = 23 Traceback (most recent call last): File stdin, line 1, in ? File stdin, line 9, in __setattr__ AttributeError: can't set attribute r.addReadOnly(a, 23) Traceback (most recent call last): File stdin, line 1, in ? File stdin, line 5, in addReadOnly File stdin, line 9, in __setattr__ AttributeError: can't set attribute I don't guarantee this completely fits the bill but I'm sure you can adapt it from here. Also note that, strictly speaking, you can't make a true read-only attribute, only one that alerts a programmer if they try the simple way. In a pure-Python object, there is always a way in. This shouldn't worry you if you're using Python (We're all consenting adults here), but you should also be aware of that. That said, this is certainly useful in the real world. -- http://mail.python.org/mailman/listinfo/python-list
Re: dinamically altering a function
What i want is to declare in the decorator some code that is common to all these functions, so the functions assume that the decorator will be there and wont need to duplicate the code provided by it, and the functions are not known ahead of time, it has to be dynamic. This sounds like a call for a Pythonic varient on the Template pattern: class Root(object): def __init__(self): self.dataChunk = 22 # or whatever class Child(Root): def __call__(self): print self.dataChunk c = Child() c() 22 Don't be put off by the OO-ness here, it acts just like a function thanks to __call__, and behind the scenes you get full OO support for your functions. I strongly suspect this is the best solution to your problem, not a decorator. Note whatever you are doing to create the functions can be done in other ways, especially note that class statements are executed, not declarations, for instance: import operator class Root(object): ... def __init__(self): ... self.op1 = 22 ... self.op2 = 44 ... funcs = [] for op in operator.add, operator.sub, operator.pow: ... def newfunc(self, basefunc = op): ... print basefunc(self.op1, self.op2) ... class New(Root): ... __call__ = newfunc ... funcs.append(New) ... funcs # show the classes [class '__main__.New', class '__main__.New', class '__main__.New'] [x() for x in funcs] # show the new functions [__main__.New object at 0xb7e78bcc, __main__.New object at 0xb7e78e4c, __ma in__.New object at 0xb7e78ecc] [x()() for x in funcs] # call each of the functions, note no return 66 -22 116572995441436549620289361494791139391860487905922101805056 [None, None, None] Upshot is, with a bit of creativity this can do whatever you want, in conjection with dynamically-created classes, no bytecode hacks, no really weird decorators, just standard OO and __call__. -- http://mail.python.org/mailman/listinfo/python-list
Re: a RegEx puzzle
On Fri, 11 Mar 2005 08:38:36 -0500, Charles Hartman wrote:
I'm still shaky on some of sre's syntax. Here's the task: I've got
strings (never longer than about a dozen characters) that are
guaranteed to be made only of characters 'x' and '/'. In each string I
want to find the longest continuous stretch of pairs whose first
character is 'x' and the second is either mark. So if marks =
'/xx/xxx///', the winning stretch begins at position 2 and is 6
characters long ('x/xxx/')
I don't think regexes are a good match for this task. They just aren't
optimized for this very well.
Here's what I have, though I don't know if it's *exactly* what you want:
def xCounter(s, initialOffset):
offset = initialOffset
count = 0
slen = len(s)
while s[offset] == 'x':
count = count + 1
offset += 2
if offset slen:
break
return count, s[initialOffset:offset]
def longestRun(s):
return max([xCounter(s, i) for i in range(len(s))])[1]
In other words, start at all the positions and find the max, sort of by
hand.
(In particular, I don't know how this will handle two runs of equal size,
if it will prefer the first or the last. I don't know how *you* handle
that, either, so I'm not sweating it for now. If you clarify this I can
help, the easiest way is to add another number into the tuple that
xCounter generates for max to work on.)
This is not optimized, and if you're processing millions of these, this
may be too slow. What I'd suggest is that if this isn't fast enough,
memoize the function, i.e., with this:
longestRunResults = {}
def memoizedLongestRun(s):
try:
return longestRunResults[s]
except KeyError: pass
result = longestRun(s)
longestRunResults[s] = result
return result
You'll probably want to change the names of things to better fit.
This will get you the benefits of pre-computation without paying the
up-front costs (you only compute what you need, not all possible
combinations), and this ought to be plenty fast to process a whole lotta
data really quickly.
(This is a great example of why readable code can be more important than
fast code; the speedup can be added later, it's more important that you
can satisfy yourself that the code is correct, and a clever algorithm
might make that hard.)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Adapting code to multiple platforms
On Fri, 11 Mar 2005 17:27:06 -0700, Jeffrey Barish wrote: Most of my program lives in a class. My plan is to have a superclass that performs the generic functions and subclasses to define methods specific to each platform I'm just getting up to speed on Python and OOP, so I'm wondering whether I have missed something obvious. I'm hoping that the strongest rebuke would be that I found something obvious. You may be interested to know this is called the Template Pattern. http://home.earthlink.net/~huston2/dp/templateMethod.html Generally, while most of the patterns are obvious in hindsight they are not necessarily obvious in advance, and I consider independently re-discovering a pattern is a good sign; it's much easier to correct not knowing about them than gaining the skills to independently re-derive them. -- http://mail.python.org/mailman/listinfo/python-list
Re: yield_all needed in Python
On Thu, 03 Mar 2005 20:47:42 +, Paul Moore wrote: This can probably be tidied up and improved, but it may be a reasonable workaround for something like the original example. This is why even though in some sense I'd love to see yield *expr, I can't imagine it's going to get into the language itself; it's too easy to do it yourself, or provide a library function to do it (which would A: Be a lot easier if we had some sort of iterable interface support and B: Be a great demonstration of something useful that really needs protocol support to come off right, because isinstance(something, GeneratorType) isn't sufficient in general). Abstractly I like the star syntax, but concretely I'm not a big fan of adding something to the language that can be done right now with a fairly short function/generator and hardly even any extra keystrokes to invoke it when done right, and that overrides my abstract appreciation. -- http://mail.python.org/mailman/listinfo/python-list
Re: yield_all needed in Python
On Wed, 02 Mar 2005 22:54:14 +1000, Nick Coghlan wrote: Douglas Alan wrote: Steve Holden [EMAIL PROTECTED] writes: Guido has generally observed a parsimony about the introduction of features such as the one you suggest into Python, and in particular he is reluctant to add new keywords - even in cases like decorators that cried out for a keyword rather than the ugly @ syntax. In this case, that is great, since I'd much prefer yield *gen1(arg) If you do write a PEP, try to get genexp syntax supported by the yield keyword. That is, the following currently triggers a syntax error: def f(): yield x for x in gen1(arg) H. At first I liked this, but the reason that is a syntax error is that it is supposed to be def f(): yield (x for x in gen1(arg)) which today on 2.4 returns a generator instance which will in turn yield one generator instance from the genexp, and I am quite uncomfortable with the difference between the proposed behaviors with and without the parens. Which sucks, because at first I really liked it :-) We still would need some syntax to say yield this 'in place' rather than as an object. Moreover, since yield is supposed to be analogous to return, what does return x for x in gen1(arg) do? Both it returns a list and it returns a generator have some arguments in their favor. And I just now note that any * syntax, indeed, any syntax at all will break this. You know, given the marginal gains this gives anyway, maybe it's best off to just observe that in the event that this is really important, it's possible to hand-code the short-circuiting without too much work, and let people write a recipe or something. def genwrap(*generators): while generators: try: returnedValue = generators[-1].next() if hasattr(returnedValue, 'next'): generators.append(returnedValue) continue yield returnedValue except StopIteration: generators.pop() Not tested at all because the wife is calling and I gotta go :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: yield_all needed in Python
On Tue, 01 Mar 2005 12:42:51 -0600, Skip Montanaro wrote: yield expr yield *expr (Mu-hu-ha-ha-ha!) -- http://mail.python.org/mailman/listinfo/python-list
Re: compatbility of .pyc files
On Wed, 23 Feb 2005 13:31:12 +1300, Blair Hall wrote: I have a requirement to prevent 'accidental' tampering with some software written in Python. If I ensure that all of the modules concerned are compiled into .pyc's, and remove the .py's to another location, then I should be safe until the next upgrade of the Python interpretter. Depending on how scare quote-y the scare quotes are, if you're really out to avoid accidental tampering, why not just set the *.py files to read-only? Beyond that you get into rapidly diminishing returns; removing the .py files is feasible if you have some semblance of control over the interpreter, beyond that and you're usually better off with a binding legal agreement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with research
On Thu, 17 Feb 2005 15:51:47 -0800, elena wrote: I can go to my friends, however it occurred to me that it might be better to post in a newsgroup and get a larger, more diverse, and random sample. Larger, yes, more diverse, yes, more random, probably not in the statistical/scientific sense. Caveat emptor. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
On Fri, 18 Feb 2005 14:14:55 +1100, news.sydney.pipenetworks.com wrote: I always wished computer science was more engineering then philosophy. That way there'd always be an obvious answer. I hear that! To be fair, computer *science* is more like mathematics than philosophy; once a correctly-framed question has been asked there is only one answer, or at least the answers are definite, or definite in their indefiniteness. (For the most part.) We're programming here though, and there we are groping through the formless void, arguing about whether my infinitesimal is better than your infinitesimal. Sorry, I was Zenning it out too, I guess. :-) By the way, just to be clear, my infinitesimal's dad can beat up your infinitesimal's dad any day of the week. (Looks like the Zen mood has passed...) -- http://mail.python.org/mailman/listinfo/python-list
Re: perl -p -i -e trick in Python?
On Wed, 16 Feb 2005 15:18:57 +0900, Wonjae Lee wrote: I read the comment of http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277753. (Title : Find and replace string in all files in a directory) perl -p -i -e 's/change this/..to this/g' trick looks handy. Does Python have a similar trick? Or, is there a shorter Python recipe for the given problem? As a Python lover... I still tend to use perl -pi -e, except in rare cases where I either can't deal with or don't want to deal with the necessary escaping, in which case I write a quick perl script like this (just did this today): #!/usr/bin/perl $source = join , ; $source =~ s/\\\.*?\\\[ \n]*//gs; print $source; While a Python-golf contest might be able to beat that (although, truthfully, to match this feature for feature I'd be surprised... that is a substantial whack of code to fully emulate and I use this both as a pipe and by feeding it a long list of files as arguments), I still couldn't have written it as quickly. Upshot is, perl is good for something, and when I'm not doing the job I have working with perl, I'll still reach for perl -pi -e without shame. Well, actually, only with the shame that I really need to lookup the command to save backups and start using it. (man perlrun... I know where to find it, I just need to add it to muscle memory!) Much longer than this though and I drop the perl and run away, if possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 14:45:09 -0800, Robert Kern wrote: Until such matters are unequivocally determined in a court that has jurisdiction over you, do you really want to open yourself to legal risk and certain ill-will from the community? Huh? What are you talking about? I'm just pointing out the inability of the law to handle it. I have no intention of doing anything with it, except inasmuch as it makes it difficult to license my own works since I don't believe any license works. (But I use the LGPL anyways.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 13:57:47 +0100, Josef Dalcolmo wrote: You can distribute GPL'ed code in binary form, you just have to make the sources available as well. And, yes I would use this as a test: if your program needs gpl-ed code for some of it's functionality, you have to licence your program according to the GPL - unless you distribute the GPL'ed parts separately and your program is still basically functioning without the GPL'ed code. The problem with this is what I've called the patch hole in another context [1]. The problem with this definition is that I can *always* distribute GPL'ed parts separately and re-combine them arbitrarily upon execution, and it's not even particularly hard. Write your code with the GPL'ed code embedded. At the end, before you distribute, extract it and record the extraction so your program can rewind it; you're left with nothing in your code that is GPLed. Later, the user will go get the GPL software, and you software rewinds the extraction process, and the user is left with something that is byte-for-byte identical to what you weren't allowed to distribute by the GPL so what good was the GPL? (Compiling issues can of course be extracted away, which is what a linker does.) If this is all the protection that the GPL provides, than it is utterly useless. But truly nailing down what it means is even harder. Nobody really knows what the GPL means when it gets down to it; the entire copyright-based model is broken and unrepairable in a software context. It's like nailing jello to a wall, you just can't hold it up there. [1]:http://www.jerf.org/writings/communicationEthics/node10.html#SECTION000105000 -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP
On Fri, 11 Feb 2005 22:23:58 +1000, Nick Coghlan wrote: This is one of the reasons why Steven's idea of switching to proposing a new module is a good one. It then provides a natural location for any future extensions of the idea such as Records (i.e. namespaces with a defined set of legal fields) and NamedTuples and NamedLists (i.e. namespaces with a defined field order) I'm not very good at reading Guido's mind, but it might be worth feeling out whether mentioning this will improve the chances of this passing or not, because while I do not know, can not know, and am not trying to predict, it is at least possible that Guido may feel as I have been: That this proposal on its own isn't that exciting, but as the foundation of some *other* standard functionality as described it might be very good. In that case that should be emphasized. See, now it still doesn't make me jump up and down because I can write what I need fairly easily, but it would be a great boon to beginners or people who just want to do work and re-write this again, but slightly differently, and would also provide some standardization where otherwise we all roll our not-quite-similar-enough implementations, which would help us read each other's code. Y'all are bringing me around, slowly but surely :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
On Fri, 11 Feb 2005 18:24:22 +0100, Damjan wrote: What you described is not ok according to the GPL - since you distributed a binary thats derived from GPL software (and you didn't publish it source code under the GPL too). No you didn't. You distributed a binary completely free of any GPL code whatsoever. The *user* combined your binary and the GPL to produce another binary, which will never be distributed at all. In copyright terms, which is what the GPL works under since that is the law it has, what you distributed is completely unrelated to the GPL'ed program; there's no grounds to call it derived. You may need to re-read the sequence more carefully, or I may have gotten it wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP
On Thu, 10 Feb 2005 11:56:45 -0700, Steven Bethard wrote: In the empty classes as c structs? thread, we've been talking in some detail about my proposed generic objects PEP. Based on a number of suggestions, I'm thinking more and more that instead of a single collections type, I should be proposing a new namespaces module instead. Context: I've never been excited by this proposal. But I am intrigued to note that with a couple of differences, you've now converged on a module I've already written for my own use, which I called a Registry. I actually subclassed 'dict', added some methods to use dotted-access as you describe, and added some methods for accessing and initializing a deeper key (basically a get that can handle hierarchy) and a couple of other things. There are worse things for application config storing than a pickled Namespace. (Not human readable, but if you don't care about that, as I generally don't, it's close to usable.) -- http://mail.python.org/mailman/listinfo/python-list
Re: namespaces module (a.k.a. bunch, struct, generic object, etc.) PEP
On Thu, 10 Feb 2005 13:39:29 -0700, Steven Bethard wrote: Yeah, I guess that was really the motivation of this module. I personally wouldn't use it all that often -- certainly not with the frequency that I use, say, Python 2.4's set type -- but I think there are enough of us out here who have written essentially the same module enough times that it merits a little bit of standardization and addition to the standard library. If it expands past what was basically a slight elaboration on class Bunch: pass to actually do real work, I'd be much more impressed, as long as simple things stay simple. A hierarchy-aware get might be a good start: config = Namespace() myParm = config.get(myapp.wrapping.line, constants.STRICT) someParms = config.get(myapp.settings.printer, Namespace()) which would create the necessary namespaces or something. -- http://mail.python.org/mailman/listinfo/python-list
Re: Name of type of object
On Wed, 09 Feb 2005 21:57:15 +, Jive Dadson wrote: But that works only if the exception happens to be derived from Exception. How do I handle the general case? I believe the answer is that Exceptions not derived from Exception shouldn't be thrown; it's basically a deprecated feature and has been for a long time. I've never seen it happen. Add another except clause and use it to bitch at the user for throwing something that isn't an Exception :-) You won't find any other code that throws anything but an exception, unless either you or your user wrote it. -- http://mail.python.org/mailman/listinfo/python-list
Re: A great Alan Kay quote
On Wed, 09 Feb 2005 15:57:10 -0800, has wrote: I'd say Python is somewhere in the middle, though moving slowly towards 'agglutination' in the last couple years. But it feels really badly about that and promises to kick the habit somewhere around the year 3000. -- http://mail.python.org/mailman/listinfo/python-list
