Re: tough-to-explain Python
> I V (IV) wrote: >IV> On Fri, 10 Jul 2009 16:27:12 -0400, Terry Reedy wrote: >>> a bug, bug a limitation due to using limited-range numbers. If one uses >>> residue classes instead of integers, and makes no adjustment, I consider >>> it wrong to blame Bentley. >IV> But it was Bentley himself who used the C int type, so it hardly seems >IV> unreasonable to blame him. If you are on a 32-bit machine, and the array to be searched contains ints, floats or doubles, the the array must be < 2^32 bytes in size, and as each element is at least 4 bytes, the indices are less than 2^30, so l+u < 2^31. Therefore there is no overflow at all. I think the Bentley programs were formulated in terms of arrays of ints. So his implementations were safe. If you are on a 64-bit machine you shouldn't use int for the indices anyway (supposing int is 32 bits) but longs and then the same reasoning shows that there are no overflows. Only when you have an array of shorts or bytes (chars) you get the problem. In that case the alternative formulation l + (u-l)/2 is more robust and therefore preferable. -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter only: table widget with canvas...
> > There's a working app at http://cl1p.net/tkinter_table_headers/ > > -John Thank you for this example. However, one issue to that... When resizing the window (vertical) then the header moves away from the table. How can I avoid this with the grid? With "pack" I now this... -- http://mail.python.org/mailman/listinfo/python-list
Re: windows explorer integration
2009/7/11 Laurent Luce : > Do you know if it is possible to write a plugin for windows explorer using > win32 module ? Yes, I believe it is. There are a number of Python projects (I believe TortoiseHg is one) that do this sort of thing. However, I don't know anything about how to do it - you should check MSDN, the PyWin32 samples, and maybe something like TortoiseHg, for sample code. Paul. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automate rsync w/ authentication
In article <3af970b1-b454-4d56-a33f-889ecfaca...@l28g2000vba.googlegroups.com>, Bryan wrote: > >rsyncExec = '/usr/bin/ssh' >source = '[email protected]:/home/bry/jquery.lookup' >dest = '/home/bry/tmp' >rshArg = '-e "/usr/bin/ssh -i /home/bry/keys/brybackup.key"' >args = [rsyncExec, '-a', '-v', '--dry-run', rshArg, source, dest] I think you want -e and the ssh command to be separate args. Something like: rshArg = '/usr/bin/ssh -i /home/bry/keys/brybackup.key' args = [rsyncExec, '-a', '-v', '--dry-run', '-e', rshArg, source, dest] or: rshArgs = [ '-e', '/usr/bin/ssh -i /home/bry/keys/brybackup.key' ] args = [rsyncExec, '-a', '-v', '--dry-run'] + rshArgs + [ source, dest] Gary Duzan Motorola H&NM -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with keys combination!
> Blocking Ctrl-Alt-Del leaves the power switch or maybe the plug as the > only way for the user to regain control. Why would you want to do that? ONly for the reason that I explaine above...is for my little joke application ! And I want disable all keys for about 30 seconds (time to erase background) I read about getasynckey() to intercept a key...but I don't know how to change key pressed with another...maybe a solution ? Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Why not enforce four space indentations in version 3.x?
On Jul 10, 2:22 pm, walterbyrd wrote: > I believe Guido himself has said that all indentions should be four > spaces - no tabs. > > Since backward compatibility is being thrown away anyway, why not > enforce the four space rule? > There is a routine in the Scripts directory, reindent.py, that will take your source file(s) and remove tabs, unify the indents to 4- spaces, remove needless characters at the end of lines, etc. IIRC, it was written by Tim Peters. We run all of our source files though before checking them into svn. --greg -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
"Steven D'Aprano" wrote: >On Fri, 10 Jul 2009 12:54:21 +0200, Hendrik van Rooyen wrote: > >> "Steven D'Aprano" wrote: >> >>>On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote: >>> > persistent idea "out there" that programming is a very accessible > skill, like cooking or gardening, anyone can do it, and even profit > from it, monetarily or otherwise, etc., and to some extent I am Programming is not like any other human activity. >>> >>>In practice? In principle? Programming in principle is not the same as >>>it is performed in practice. >>> >>>But in either case, programming requires both the logical reasoning of >>>mathematics and the creativity of the arts. Funnily enough, >> >> I do not buy this arty creativity stuff. - or are you talking about >> making a website look pretty? > >I must admit, it never crossed my mind that anyone here would claim that >there was no creativity involved in programming, that it was all a >mindless, algorithmic process capable of being done by a simple >mechanical device. "Programming" is the step of going from the "design" to something that tells the machine how to implement the design. The creativity could, arguably, be in the "Design". Not in the translation to python, or assembler. No way. That is just coding. > >This is certainly the accusation made against *bad* programmers -- that >they can't actually solve new, unique problems, but just apply recipes >they learned without any insight or intelligence. The sort of people who >program so poorly that "a trained monkey could do what they do". > >Do you really think that applies to good programmers too? If so, then a >good code generator should be able to replace any programmer. Is that >what you believe? > Should eventually be possible, with sufficient restrictions to start off. UML wants to go this route... But may my eyes be stopped and my bones be heaped with dust ere I see the day... > > >>>mathematicians will tell you that mathematics requires the same, and so >>>will the best artists. I think mathematicians, engineers, artists, even >>>great chefs, will pour scorn on your claim that programming is not like >>>any other human activity. >> >> So a chef is now an authority on programming? > >Did I say that? No. I just read it like that to irritate you. > >Chefs are authorities on OTHER HUMAN ACTIVITIES. > > > >> Programming is actually kind of different - almost everything else is >> just done, at the time that you do it. >> >> Programming is creating stuff that is completely useless until it is fed >> into something that uses it, to do something else, in conjuction with >> the thing it is fed into, at a later time. > >Somebody should teach Hendrik that human beings have been creating TOOLS >for hundreds of thousands of years. People have been creating tools to >build tools for thousands of years. Software is just more of the same. I disagree - I actually own some machine tools, so I am a little bit acquainted with what they can do, and it is not at all like computing at any level I can think of - they are merely extensions of the hand, making the transformation of materials more accurate and faster. The line only becomes blurred when a processor is added, and a STORED PROGRAM is brought into the equation. > >Even *soup stock* fits the same profile as what Hendrik claims is almost >unique to programming. On its own, soup stock is totally useless. But you >make it, now, so you can you feed it into something else later on. > >Or instant coffee. > >No, Henrik, if that's the best you can do, it's not very good. It is >rather sad, but also hilarious, that the most different thing you have >noticed about software is that it's just like instant coffee. > You have a wonderful ability to grab hold of part of a definition and to ignore the rest, just like I can misread what you write. Coffee and soup stay coffee and soup on re hydration. Mixing it in with something else is not at all the same - it does not "DO" anything else in conjunction with the thing it is fed into - how is that like programming, and executing a program? I am sorry if you are confusing the drinking of coffee, which is an ancilliary activity to programming, with the actual programming itself. > > >> This is a highly significant difference, IMHO. > > >>>[...] He talks about how "when all is said and done, the only thing computers can do for us is to manipulate symbols and produce results of such manipulations" and he emphasises the "uninterpreted" nature of mechanical symbol manipulation, i.e. that the machine is doing it mindlessly. >>> >>>"Manipulate symbols" is so abstract as to be pointless. By that >>>reasoning, I can build a "computer" consisting of a box open at the top. >>>I represent a symbol by an object (say, a helium-filled balloon, or a >>>stone), instead of a pattern of bits. I manipulate the symbol by holding >>>the object over the box and letting go.
Re: tough-to-explain Python
"pdpi" wrote; >I've always found cooking an apt metaphor for programming. No this is wrong. Writing a recipe or a cookbook is like programming. Cooking, following a recipe, is like running a program. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter only: table widget with canvas...
There's a working app at http://cl1p.net/tkinter_table_headers/ Thank you for this example. However, one issue to that... When resizing the window (vertical) then the header moves away from the table. How can I avoid this with the grid? With "pack" I now this... Oops ... packing can be tricky. Try these modifications: header_frm.pack(side=TOP, anchor=W, expand=False) ... table_frm.pack(side=TOP, expand=True, fill=BOTH) You also might try constraining the top-level (root) window, using these methods: rt.geometry(XXX, YYY) rt.resizable(False, True) -John -- http://mail.python.org/mailman/listinfo/python-list
Re: Addind imports to a class namespace
Thanks for your help Peter. I'm thinking that perhaps this isn't a circular import and that I don't understand importing. Here is a better explanation of my case (I am using Django): I have file x.py that declares classes A, B, C. There is also a file y.py that contains two methods T, U and the class that we are talking about above. x.py uses a dispatcher system to connect a signal to methods T and U in y.py so it does: from y import T, U. y.py needs to use classes A, B, C which is basically Menu and Link (and some other class) above so I am thinking that if in y.py I have from x import A, B, C that will cause a circular import? Is this not correct and if it isn't can you explain why? Does using from ... import X, Y, Z, i.e. explicit imports avoid this problem or does it exacerbate it? Thanks, Ryan -- http://mail.python.org/mailman/listinfo/python-list
Re: windows explorer integration
Hi! Possible! With Pywin32. I see two ways: - add a "toolBar" ; see the exemple for Internet-Explorer (it run for both, IE & explorer) - add an entry in the context menu (right click) @-salutations -- Michel Claveau -- @-salutations Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: psyco V2 beta2 benchmark
larudwer, is that time_subdist subdist(i) a bad worsening? Something to be fixed in Psyco2? Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
Steven D'Aprano wrote: Even *soup stock* fits the same profile as what Hendrik claims is almost unique to programming. On its own, soup stock is totally useless. But you make it, now, so you can you feed it into something else later on. Or instant coffee. I think I'll avoid coming to your house for a cup of coffee. :-) --Scott David Daniels [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: Addind imports to a class namespace
Ryan K wrote: > I'm thinking that perhaps this isn't a circular import and that I > don't understand importing. Here is a better explanation of my case (I > am using Django): > > I have file x.py that declares classes A, B, C. Classes in Python are executable code, just like import-statements. That's why there is no Python equivalent to forward declarations in other languages; every name has to be known at the point where it occurs in the module. > There is also a file y.py that contains two methods T, U and the class > that we are talking about above. > > x.py uses a dispatcher system to connect a signal to methods T and U > in y.py so it does: from y import T, U. > > y.py needs to use classes A, B, C which is basically Menu and Link > (and some other class) above so I am thinking that if in y.py I have > from x import A, B, C that will cause a circular import? Yes. Having x import y and y import x creates a cycle. If you cannot avoid this by moving to a simpler design you can always introduce a third module z that imports x and y, and then explicitly resolves the circular references. > Is this not correct and if it isn't can you explain why? Does using > from ... import X, Y, Z, i.e. explicit imports avoid this problem or > does it exacerbate it? It has no effect. from module import X is equivalent to import module X = module.X del module # just the name, not the module itself Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
On Sat, 11 Jul 2009 14:01:25 +0200 "Hendrik van Rooyen" wrote: > "Programming" is the step of going from the "design" to something > that tells the machine how to implement the design. > > The creativity could, arguably, be in the "Design". > Not in the translation to python, or assembler. > No way. That is just coding. One might also argue that divorcing the design from the code is the problem in a lot of legacy code. See Agile Programming methods. Now you could say that there is a design step still in talking to the client and making a plan in your head or in some notes but that's like saying that Michelangelo was done creating after discussing the Sistine Chapel with Pope Sixtus and that the rest was just a house painting job. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
"D'Arcy J.M. Cain" > One might also argue that divorcing the design from the code is the > problem in a lot of legacy code. See Agile Programming methods. Now > you could say that there is a design step still in talking to the > client and making a plan in your head or in some notes but that's like > saying that Michelangelo was done creating after discussing the Sistine > Chapel with Pope Sixtus and that the rest was just a house painting job. How do you know that it was not exactly like that - he did, after all, take a much longer time than expected to complete the job - just like a house painter that gets paid by the hour. :-) It is also unreasonable to assume the opposite fallacy - that he was in a creative frenzy from the start to the time at the end when he was cleaning his brush after applying the last spot of paint. But it is a valid point - it is often difficult to draw the line between the design and the implementation - and one of the reasons that we all like to program in python, is that it is almost a language that is a design language that can also be run directly. - I have lately been doing stuff like writing rough prototypes using python syntax to serve as designs for some of the assembler thingies I do. If you muck around a bit at the lower level, you will also be more aware of the dichotomy between the design and the implementation - in python, it is not obvious at all. In assembler, it is glaring. But in either place, if you get it wrong, you suffer. - your programs cripple along, or they hardly do what you thought they would, and they bear no relationship with what the customer wanted. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
John O'Hagan wrote: >The drawings produced by an architect, the script of a play, the score of a piece of music, and the draft of a piece of >legislation are all examples of other things which are "useless" until they are interpreted in some way. Granted. But... >There are countless human activities which require a program, i.e. a conscious plan or strategy, formed at least partly >by a creative process, and a computer program is just a special case of this. The difference is that for a piece of music, or a recipe for "bobotie", there is room for artistry also in the performance or preparation. If the piece of music is reduced to a scroll with holes in it and played on a pianola, then nobody in his right mind would call the mechanically produced sounds "a great performance". And this is the essential difference that sets programming apart from cookbook writing or drawing architectural plans - the one thing that makes the real difference is the mindlessness of the performer. (maybe I should conceed that writing legislation is a form of programming, as the constabulary does not have a reputation for anything other than a plodding consistency) >I use Python as a tool for writing music, but I find I need both logical reasoning and creativity to do either. In fact, I >find programming very similar to writing music in a rigorous contrapuntal style, where each set of choices constrains >each other, and there is a deep aesthetic satisfaction in getting it right. Getting it right has to do with the design, not the programming - Have you ever struggled to get something right, and then one day you take a different tack, and suddenly it is as if you cannot do anything wrong - everything just falls into place? - That is the time that you get the good feeling. The difference between the one and the other is the difference between bad or indifferent design and good design. When you have a good design, the rest follows. If your design is crud, no matter what you do, you struggle and nothing comes out just right, despite heroic effort. Now this stuff is easy to talk about, and immensely difficult to do - it takes experience, some skill, some cunning, and a willingness to experiment in an egoless fashion, amongst other things. And then the stupid compiler completely screws up your intent... :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: hoe to build a patched socketmodule.c
Scott David Daniels wrote: > jacopo mondi wrote: >> Roger Binns wrote: >>> jacopo mondi wrote: Hi all, I need to patch socketmodule.c (the _socket module) in order to add support to an experimental socket family. >>> You may find it considerably easier to use ctypes since that will avoid >>> the need for any patching. You'll also be able to control how read and >>> write are done (eg read vs recvfrom vs recvmsg vs readv). You can use >>> os.fdopen to convert your raw file descriptor into a Python file object >>> if appropriate. > > The typical Python way of dealing with this is an additional module, not > a modified module placed back in the library. So, take the sources and > edit, but change the module name. Even better is figure out how to > use _socket.pyd, to create a smaller _socketexpmodule.c and use that. > > --Scott David Daniels > [email protected] Thanks a lot Scott. If I'll write a new module, with a new name, based on socketmodule.c I will not be able to ditribuite the source code and make users compile it using distutils, instead I have to compile it using the whole python build system (changing setup.py in python sources to let it know about my new module) and distribuite the compiled .so with a script to install it, I suppose. Anyway, that's not too bad... Reusing _socket.so, or the main wrapper socket.pyc I think is not possible, because I need to modify low level functions that are not exposed thanks again jacopo -- http://mail.python.org/mailman/listinfo/python-list
Re: Addind imports to a class namespace
Okay so below is the acutal code. I am starting to think there is no reason why I can't install the post_save signal in signals.py itself and thereby avoid this issue entirely. models.py: class Link(CommonAbstractModel): ... class Menu(CommonAbstractModel): class StaticPage(CommonAbstractModel): ,,, class CachedMenuXhtml(CommonAbstractModel): ... post_save.connect(signals.build_menu, sender=Link) post_save.connect(signals.build_menu, sender=Menu) # Signlas for caching of menu XHTML class GenerateMenuXhtml(threading.Thread): def __init__(self, instance): from asqcom.apps.staticpages.models import Menu, Link, CachedMenuXhtml self.Link = Link self.Menu = Menu self.CachedMenuXhtml = CachedMenuXhtml # Function to run on post_save signal def build_menu(sender, instance, **kwargs): GenerateMenuXhtml(instance).start() -- http://mail.python.org/mailman/listinfo/python-list
asyncore's lack of sendto(), recvfrom()
Is there any good reason why sendto() and recvfrom() aren't wrapped by asyncore? Obviously, recvfrom() cannot be replaced by recv(), but even sendto() cannot be replace by connect() and send(), either: I'm writing a traceroute module, and I found out that under the current firewall configuration of my OS, sending an ICMP packet via sendto() doesn't trigger a connection confirmation (the packet is silently and successfully sent), while connect() does (the firewall reports an attempted UDP connection, I'm sure why). I know Python merely wraps send() and sendto() from of the OS, obviously there are some important subtle differences between the two. Now, if I'd want to add sendto() and recvfrom() to asyncore, would it be sufficient to simply copying its send() and recv() wrapper functions and change the names and arguments, or are there more modifications required? -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Addind imports to a class namespace
Ryan K wrote: Thanks for your help Peter. I'm thinking that perhaps this isn't a circular import and that I don't understand importing. Here is a better explanation of my case (I am using Django): I have file x.py that declares classes A, B, C. There is also a file y.py that contains two methods T, U and the class that we are talking about above. x.py uses a dispatcher system to connect a signal to methods T and U in y.py so it does: from y import T, U. y.py needs to use classes A, B, C which is basically Menu and Link (and some other class) above so I am thinking that if in y.py I have from x import A, B, C that will cause a circular import? Is this not correct and if it isn't can you explain why? Does using from ... import X, Y, Z, i.e. explicit imports avoid this problem or does it exacerbate it? Thanks, Ryan You indeed have described a circular import. In this case, a mutual dependency exists between x.py and y.py. This can and nearly always should be avoided. That's independent of the language involved, in any language, circular dependencies are a code smell Now, in Python in particular, first question is whether either x.py or y.py is your main script module (the one where you do the if __name__ == "__main__" and the answer is yes). If so, you're in big trouble, and you really need to rework it. I could elaborate if needed, but trust me, you don't want to do this, even if it means writing one more module containing a single import line and just two or three more, and letting that be your script. If that's not the case, next question is whether either module refers to the other one at import time, or only from inside def and class definitions. If you have any top-level code going on, other than imports, and this code actually uses a symbol from the other module, you're probably in trouble. Not as bad as first case, but still worth avoiding. Sometimes this can be kludged past, by reordering things a little bit, maybe by moving one of the imports further down in the file. Now back to the code smell. If the modules really depend on each other, you should consider factoring out those dependencies and move them to a third module that both import. Figure out why the modules are broken up in the particular way they are, and how you can eliminate circular references by refactoring. It's hard for me to come up with general principles, but perhaps an example or three will help. If a callee needs configuration information stored in globals of the caller, then you probably need to add that config information as parameters. If an object needs a reference to functions in another module, add them when constructing the object, not statically. Or maybe even have the one module explicitly set global variables in the other module, so they're in one place, instead of being only in the namespace of the code initializing them. That's the best I can do without something concrete to adjust. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Clarity vs. code reuse/generality
2009/7/11 Steven D'Aprano : > So is design-by-contract just another way of saying "let's hope the data > is valid, because if it's not, we're screwed"? Not at all. Design By Contract is about assigning responsibility for checking. If you don't assign responsibility then a pile of things end up getting checked over and over again, because everybody is assuming responsibility, and some things don't get checked at all because everyone assumes that somebody else is checking. In DbC, the pre-condition on data coming in to a program from outside will usually simply be "true" -- nothing at all is assumed about it. But when you pass it from an input conditioning routine to a processing routine, the input conditioning routine should be able to make guarantees about what it passes, and the processing routine should be able to assume that those guarantees are met without having to check it again (after all, what was the conditioning routine there for?). Assertions might be useful in testing (because they save having to repeat the same set of test cases on absolutely every test run) and they're certainly useful in documenting, but if they're any use at all in the production run-time then there's something wrong with your development and testing processes. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Threading.Condition problem
> Gabriel Rossetti (GR) wrote:
>GR> Sorry if this appears twice, I sent it once with an attachment and it never
>GR> arrived so maybe the attachment is posing problems. I inlined the code this
>GR> time (at the bottom), thank you,
>GR> Gabriel
>GR> ## Original message
>GR> Hello everyone,
>GR> I wrote a small example that listens for xmpp msgs in a thread. The main
>GR> program calls a function that blocks (using Condition.wait) until a msg
>GR> has been received and then returns the msg. When a msg arrives, it is
>GR> put in a variable in the thread's object, it then calls the notify()
>GR> attr on the Condition object. For some reason, this doesn't work, the
>GR> thread gets the msg, tries to notify the Condition object, fails because
>GR> the lock has not been acquired yet and blocks. I tried ignoring the
>GR> failure, thinking that since it has not been acquired yet then when it
>GR> is, it will get the msg right away and never call Condition.wait, thus
>GR> not causing any problems, but this does not work either. Does someone
>GR> know what I am doing wrong? I attached the code to this msg.
The code that puts the message in the variable should also acquire the
lock:
def onMessage(self, conn, msg):
with self._cv:
self.message = msg
self._cv.notify()
A couple of remarks:
1. I think the code is neater if all manipulation with the condition is
done in the same class (actually in the same instance -- making this
instance into a monitor).
class Listener(Thread):
def __init__(self, ws):
Thread.__init__(self)
self.interrupt = Event()
self.message = None
self._cv = Condition()
self.client = ws._client
self.client.RegisterHandler('message', self.onMessage)
def onMessage(self, conn, msg):
with self._cv:
self.message = msg
try:
self._cv.notify()
except RuntimeError:
print "self._cv has not acquired the lock yet"
def getMsg(self):
with self._cv:
while !self.message
self._cv.wait()
return self.message
class WS(object):
def __init__(self, username, password, res):
self._jid = xmpp.protocol.JID(username)
self._client = xmpp.Client(self._jid.getDomain())
#self._cv = Condition()
def getMsg(self, mid=None):
"""
"""
return self._listener.getMsg()
Of course I haven't tested this code as I don't have the context
modules.
2. I don't know if more than one message can be delivered in the same
instance. If yes, than your code will not work, and neither will the
code above as, the message instance variable is never cleared. So the
next getMsg will be happy to deliver the previous one.
You would have to clear it when returning this one.
def getMsg(self):
with self._cv:
while !self.message
self._cv.wait()
msg = self.message
self.message = None
return msg
3. If the messages come in faster than they can be processed some will
be lost as they will overwrite the previous one in the self.message
variable. The solution is to use a threading.Queue to transfer the
messages from one thread to the other. This also saves you the hassle
of doing your own synchronisation like above. If you are not familiar
with synchronising multithreaded applications it is very easy to make
errors and even if you are it is quite easy to do them wrong. I have
been involved in distributed programming courses at university level
and I have seen many errors in this area.
--
Piet van Oostrum
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: [email protected]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Package for fast plotting of many data points in Python?
Hi, thanks for your repleys. I have tried matplotlib but it is extremely slow. I think it is more optimized for good looking plots instead of speed. I do not know the Python bindings of gnuplot and Veusz. To clarify the issue again, by 25000 data points I mean 25000 pixels, i.e. corresponding (x,y) pairs. Thus the mapping to one pixel on the screen is not unique. Now, that I have to implement this problem on my own I am very impressed by the plotting capabilities of LabView which brings thounds of data points on screen in an extremely short time. Thanks for your help. Best regards, Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: Package for fast plotting of many data points in Python?
Daniel Platz writes: > I do not know the Python bindings of gnuplot and Veusz. A web search does, though. http://clusty.com/search?query=gnuplot+python> http://clusty.com/search?query=veusz+python> -- \“The problem with television is that the people must sit and | `\keep their eyes glued on a screen: the average American family | _o__) hasn't time for it.” —_The New York Times_, 1939 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.4 VS 3.1 for simple print
In message <[email protected]>, Ben Finney wrote: > For this and other differences introduced in the Python 3.x series, see > http://www.python.org/dev/peps/pep-3100/>. People never thank you for an "RTFM" response. -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "=" (Was: tough-to-explain Python)
In message , Aahz wrote: > It helps to remember that names and namespaces are in many > ways syntactic sugar for dicts or lists. Interesting, though, that Python insists on maintaining a distinction between c["x"] and c.x, whereas JavaScript doesn't bother. -- http://mail.python.org/mailman/listinfo/python-list
Re: tough-to-explain Python
Hendrik van Rooyen wrote: The creativity could, arguably, be in the "Design". Not in the translation to python, or assembler. No way. That is just coding. No, the mechanical part of the process is called compiling, and we have programs to do it for us. By the time you've specified the design so rigorously that not the slightest spark of creativity is needed to implement it, you *have* coded it. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "=" (Was: tough-to-explain Python)
Lawrence D'Oliveiro wrote: Interesting, though, that Python insists on maintaining a distinction between c["x"] and c.x, whereas JavaScript doesn't bother. And that distinction is a good thing. It means, for example, that dictionaries can have methods without colliding with the key space of the items put into them. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
explode()
What is the Python equivalent of the PHP explode() function? Fred -- http://mail.python.org/mailman/listinfo/python-list
Re: explode()
On Sat, Jul 11, 2009 at 7:41 PM, Fred Atkinson wrote:
> What is the Python equivalent of the PHP explode() function?
some_string.split("separator")
Cheers,
Chris
--
http://blog.rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: explode()
On Sat, 11 Jul 2009 18:50:28 -0700, Chris Rebert
wrote:
>On Sat, Jul 11, 2009 at 7:41 PM, Fred Atkinson wrote:
>> What is the Python equivalent of the PHP explode() function?
>
>some_string.split("separator")
>
>Cheers,
>Chris
Thanks,
Fred
--
http://mail.python.org/mailman/listinfo/python-list
Re: A zlib question
Roland Hedberg catalogix.se> writes: > I have a problem with zlib and compressing/decompressing according to > RFC 1951. > > It seems like I can decompress, something compressed according to RFC > 1951 by someone else, provided I set wbits to something negative (used > -8 but I guess any negative number would work?). -15 will get you a 32KB window which is the best and is the default in APIs where a default is possible. original_data = zlib.decompress(deflated_data, -15) > But how can I compress using zlib so it doesn't add a gzip header ? You don't need to, because zlib doesn't add a gzip header (RFC 1952) -- it adds a zlib header (RFC 1950) ... without out any frills (i.e. default case) a zlib stream is a 2-byte header plus the RFC 1951 deflate stream plus a 4-byte checksum. deflated_data = zlib.compress(uncompressed_data)[2:-4] Coincidentally this question arose elsewhere very recently: see http://stackoverflow.com/questions/1089662/ python-inflate-and-deflate-implementations concatenate the above two lines -- gmane <= 80-byte line limit 8-P BTW FWIW, one can evidently force zlib to do a gzip wrapper instead of a zlib wrapper by setting wbits to positive > 15 [brilliant API design], but one might be better off using the gzip module directly ... HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "=" (Was: tough-to-explain Python)
In article , Lawrence D'Oliveiro wrote: >In message , Aahz wrote: >> >> It helps to remember that names and namespaces are in many >> ways syntactic sugar for dicts or lists. > >Interesting, though, that Python insists on maintaining a distinction >between c["x"] and c.x, whereas JavaScript doesn't bother. Why do you say "insists"? class AttrDict: def __getitem__(self, key): return getattr(self, key) -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "as long as we like the same operating system, things are cool." --piranha -- http://mail.python.org/mailman/listinfo/python-list
