Re: Q: multiprocessing.Queue size limitations or bug...
On Aug 26, 4:56 am, Michael Riedel
wrote:
> Sorry for being not more specific but I'm not absolutely certain whether
> I encountered a bug or did anything wrong:
>
> The (stupid) code below results in a stall forever or not at 'p0.join()'
> depending on the value of TROUBLE_MAKER.
>
> Any help, thoughts, comments?
>
> Thank you for your time.
>
> Michael
>
> # --
>
> from multiprocessing import Process, Queue
>
> # bit vector size
> BVS=8
>
> #
> TROUBLE_MAKER=12 # for greater values p0.join() is never satisfied...
>
> def evaluate(q, id, start=0, stop=2**BVS):
>
> cmin = {0: []}
>
> for mask0 in range(start, stop):
> for mask1 in range(0, 2**BVS):
> for mask2 in range(mask1, TROUBLE_MAKER):
> cmin[0].append((mask0, mask1, mask2))
>
> print 'process %d finished (dict layout: %d/%d)...' % (id,
> len(cmin), len(cmin[0]))
> q.put(cmin.copy())
> q.close()
>
> if __name__ == '__main__':
>
> q0 = Queue()
> q1 = Queue()
> q2 = Queue()
> q3 = Queue()
>
> part = 2**BVS/4
> p0 = Process(target=evaluate, args=(q0, 0, 0*part, 1*part),
> name='worker_0')
> p1 = Process(target=evaluate, args=(q1, 1, 1*part, 2*part),
> name='worker_1')
> p2 = Process(target=evaluate, args=(q2, 2, 2*part, 3*part),
> name='worker_2')
> p3 = Process(target=evaluate, args=(q3, 3, 3*part, 4*part),
> name='worker_3')
> p0.start()
> print 'process 0 started...'
> p1.start()
> print 'process 1 started...'
> p2.start()
> print 'process 2 started...'
> p3.start()
> print 'process 3 started...'
> # main process stalls at p0.join() for bigger TROUBLE_MAKER
> p0.join()
> p1.join()
> p2.join()
> p3.join()
> res0 = q0.get()
> res1 = q1.get()
> res2 = q2.get()
> res3 = q3.get()
> print 'results fetched...'
>
> # --
>
> --
There is a warning related to this in the documentation:
http://docs.python.org/library/multiprocessing.html#pipes-and-queues
Basically, you should reverse the order of the get() and join() calls.
multiprocessing does a pretty nice job of abstracting away the low-
level details of IPC, but there are still some gotchas. As you've
noticed, your program will deadlock when there is a large enough
amount of data being put into the queue. This is related to a hidden
thread that exists inside each of your child processes. The thread is
responsible for taking your queue items from an internal buffer and
then writing them into a pipe that your parent process will read from
when get() is called. The pipe mechanism is what allows the two
processes to pass information, and is supported directly by the
Operating System. However, the pipe has a limited capacity, and when
it is full, the writer thread is stuck waiting for the reader to read
enough from the pipe so that it can finish its write. The problem is
that your parent process (reader) is not actually calling get() to
drain the pipe. Instead it's stuck in join() waiting for the writer to
complete.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Wednesday 26 August 2009 17:45:54 kj wrote: > In <[email protected]> Steven D'Aprano writes: > >Why are you defining a method without a self parameter? > > Because, as I've explained elsewhere, it is not a method: it's a > "helper" function, meant to be called only once, within the class > statement itself. If the sole purpose of the function is to be used to define what will become a constant, why do you not just calculate the constant on your calculator, or at the interactive prompt, and assign it to the attribute, and be done with it? Why waste run time recalculating every time the programme is called? > > Well, this is not strictly true, because the function is recursive, > so it will also call itself a few times. But still, all these > calls happen (loosely speaking) "within the class statement". Why *must* it be there? > > In fact the only reason to use a function for such initialization > work is when one needs recursion; otherwise there's no point in > defining a function that will only be invoked exactly once. Seems no point to me even when there is recursion - a number is a number is a number. If you know the arguments when you write it, and if the function is known at time of writing, storing a literal is the best solution. Conversely, if the arguments are not known at time of writing, then they should be passed at run time, when an instance is created, and assigned as part of the __init__ method. And the same is true if the function is not known at time of writing - then it must be passed to the constructor of the instance. Storm in a teacup. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
RE: Move dictionary from instance to class level
Dave Angel wrote: > Any time I see multiple lists like that which have to stay in > synch, I think code-smell. > I don't think it is that bad, but I agree there is always room for improvement. > Why not let the EVT's be passed as strings, and avoid the whole mapping > to integers and mapping back detail? And name the methods involved in a > way that you can directly translate the string to the method name? > There is some merit in this. At present I am writing the server and the client, and copy/paste the list of constants, so they are guaranteed to stay in sync. (Maybe I should import it instead - even more fool-proof [the fool being me, of course]). However, it may happen that I want to open it up to 3rd-party clients in the future, in which case I would have to publish some sort of API. It would make more sense to identify the messages by a meaningful name rather than an integer. And yes, I could then use 'getattr' to retrieve the corresponding method on the server side. > Barring that, make a single "structure" which lists the event > names and > method names in matched pairs, and derive whatever lists and > dictionaries you actually need from that one structure. And that > structure should be shared between client and server code, > perhaps as a > text file that they both parse. Or as a stream that's passed > from one > to the other during startup. That way, consistency between > them can be > regulated (with version string in the file, for example) > I'm not sure how that would work. On the client side, I need to respond to a 'button-clicked' event from the gui system by sending an EVT_BUTTON_CLICKED message to the server. In other words it is hard-coded into the client program. I don't know how that would work if I read in a list of message-types at startup. > DaveA > Thanks for the input - it is always good to have some fresh ideas. Frank -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj wrote: I think I understand the answers well enough. What I *really* don't understand is why this particular "feature" of Python (i.e. that functions defined within a class statement are forbidden from "seeing" other identifiers defined within the class statement) is generally considered to be perfectly OK. IMO it's a bizarre, inexplicable blindspot (which, among other things, gives rise to a certain worry about what other similar craziness lurks under Python's image of rationality). I have never seen even a half-hearted justification, from a language design point of view, for why this particular "feature" is worth having. Maybe some day the BDFL will deign to give one. I attempted to give an explanation in my previous post. -- http://mail.python.org/mailman/listinfo/python-list
[OT] How do I reply to a thread by sending a message to [email protected]
Hi all I mentioned yesterday that I had a problem sending a message to the newsgroup via the Outlook Express news reader. Today I received an email from DaveA, which was sent to me via [email protected]. I tried simply replying to the email, to see if it behaved better than Outlook Express. I hit 'Reply to all', so it 'replied' to the sender and cc'ed to [email protected]. I have just checked in google-groups and my message does appear, in the correct thread, but not in its correct thread position. Is there a proper way to do this, or is it better to stick to a news reader like Outlook Express? Thanks Frank Millman P.S. I am sending this message via email to [email protected] - let's see what happens. -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Wednesday 26 August 2009 22:06:01 Esben von Buchwald wrote: > > I don't really get it... > > I can see that I should put a t.after(...) around the function that does > the work, when calling it. That delays each call for the given period. I > just tried it out, the console keeps saying > - > Traceback (most recent call last): >File "c:\resource\python25\python25.zip\sensorfw.py", line 499, in > data_cb >File "c:\resource\python25\python25.zip\sensorfw.py", line 160, in > custom_cb >File "e:\python\r3s_contextdata.py", line 79, in acc_filter > self.acc_callback() >File "e:\python\r3s_contextdata.py", line 85, in acc_callback > self.doCallback() >File "e:\python\r3s_contextdata.py", line 47, in doCallback > self.at.after(0.05,self.data_callback) > RuntimeError: Timer pending - cancel first > > - > > It seems like i should cancel the current counting timer, when a new > call comes in - but how to determine when to cancel etc? Hmm - now I am really starting to fly by the seat of my pants - but it looks as if your problem is that your routine is basically being called faster than what it can do the processing. So what I would try is to define a global (you should really acquire a lock, but forget that for the moment) So lets call this thing running_calculation. Then you set this in the routine just before the after call, and reset it just before exiting the calculation routine, and if it is set when you get into the first routine, then you just exit, without doing the after. This should have the effect of skipping some calls, to make it all manageable. Then you should (hopefully) not have the duplication that it looks to me like you are now having. Bye the way, make the time short - like 1 - it could also be that the time is now so long before you start calculating, that you do not have a snowball's hope in hell to be finished before the next value comes in. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On Wednesday 26 August 2009 22:47:23 David C Ullrich wrote: > That's great. But do you know of anything I can use as a > visual form design tool in wxPython? Boa Constructor - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
Ulrich Eckhardt a écrit : (snip) Now, what actually causes problems is that 'fact_rec' is not universally accessible until class 'Demo' is fully defined, but you need this in order to fully define it. Here comes a drawback of the dynamic nature of Python, that the declaration phase (compiling) is not separate from the execution. It is. You can manually compile a module, remove the source .py and still import (or execute) the compiled .pyc. The "problem" here is not with compilation, but with the fact that 'class' (and 'def') statements are *executable* statements. IOW, the class statement is executed when encountered, that is, usually (most class statements being top-level statements), when the module is first loaded. I fully agree that this case is rather vexing to my (and obviously your) biased brain. I wouldn't call this a bug before fully understanding why e.g. you can not access a class before its definition is finished. Nor why it's a GoodThing(tm) for quite a lot of use case - while the OP's problem is in the splitting-hairs category - only a problem if yoçu insist in imposing your views on the language instead of learning how to use it. Suggestion: someone mentioned that you should make the function a normal function. (snip) Someone (Diez Roggisch IIRC) also mentionned a simple solution that mostly fulfills the OP's desires: use a nested function. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj wrote: > Because, as I've explained elsewhere, it is not a method: it's a > "helper" function, meant to be called only once, within the class > statement itself. So why didn't you delete it after you were done with it? Class Demo(object): def fact(x): ... _classvar = fact(5) del fact() -- Stephen Fairchild -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj a écrit : (snip) I fully agree that this case is rather vexing to my (and obviously your) biased brain. I wouldn't call this a bug before fully understanding why e.g. you can not access a class before its definition is finished. I understand this, what I don't understand is why do it this way. I've been trying to understand this particular design point for *literally* years. It's quitye simple: 'class' is an executable statement that creates a class object (yes, all this happens at runtime) and bind it in the current namespace. So until the class statement is executed, the class object doesn't exist and it's name is not bound. Now if you don't understand why it's a GoodThing(tm) that all this happens at runtime, have a look at metaclasses, how they are used in most major Python frameworks, and how this allows to vastly reduce the amount of needed boring and erreor-prone boilerplate code one cand find elsewhere. I think someone mentioned one or two PEPs, which are the design documents that explain Python including the rationale, I'd use that as a starting point. I'm reading PEP 227 now, suggested by Steven D'Aprano. In it I find statements like the following alert: (Note: If a region is contained within a class definition, the name bindings that occur in the class block are not visible to enclosed functions.) I've seen this before, but never an explanation for why having this restriction. You should re-read Carl Bank's answers more carefully then. It's just one of life's mysteries. (Incidentally, the fact that the author of PEP 227 felt it necessary to add that parenthetical remark suggests that the expectation it warns against is not so crazy after all.) It's not so crazy for someone coming from a more static language. Python's object model is indeed a bit peculiar, and it can take some times getting the big picture, but be sure it has been carefully designed, and is incredibly powerfull once you start understanding the whole thing. But I'm still not done with PEP 227. Maybe I'll see the light by the time I'm done. My 2 cents : learn about metaclasses, attributes lookup rules, and the descriptor protocol (and some practical applications of these features). Then you might decide that the few resulting restrictions are really worth the price. -- http://mail.python.org/mailman/listinfo/python-list
Python on HP-UX
Hi I'm trying to compile Python on an HP-UX v11.23 running on an Itanium. I have tried with both gcc and cc, and python versions 2.5.4, 2.6.2 as well as an SVN checkout. In all cases, alloca.h needs to be included. On most systems I'm guessing it is already included from stdlib.h, but not on HP-UX. The following code in the right header file solves that problem: #ifdef __hpux #include #endif My problem is that ctypes keeps seg faulting: ./python -v Lib/ctypes/test/runtests.py [...] # Python-2.5.4/Lib/encodings/ascii.pyc matches /Python-2.5.4/Lib/encodings/ascii.py import encodings.ascii # precompiled from Python-2.5.4/Lib/encodings/ascii.pyc Segmentation fault (core dumped) ./python -v ./Lib/ctypes/test/runtests.py [...] # Python-2.6.2/Lib/ctypes/test/test_numbers.pyc matches Python-2.6.2/Lib/ctypes/test/test_numbers.py import ctypes.test.test_numbers # precompiled from Python-2.6.2/Lib/ctypes/test/test_numbers.pyc Segmentation fault Have people managed to get a working ctypes installation on HP-UX? BR, David Westlund -- http://mail.python.org/mailman/listinfo/python-list
Re: Move dictionary from instance to class level
Frank Millman wrote: Dave Angel wrote: Any time I see multiple lists like that which have to stay in synch, I think code-smell. I don't think it is that bad, but I agree there is always room for improvement. Why not let the EVT's be passed as strings, and avoid the whole mapping to integers and mapping back detail? And name the methods involved in a way that you can directly translate the string to the method name? There is some merit in this. At present I am writing the server and the client, and copy/paste the list of constants, so they are guaranteed to stay in sync. (Maybe I should import it instead - even more fool-proof [the fool being me, of course]). However, it may happen that I want to open it up to 3rd-party clients in the future, in which case I would have to publish some sort of API. It would make more sense to identify the messages by a meaningful name rather than an integer. And yes, I could then use 'getattr' to retrieve the corresponding method on the server side. I've built such pairs of programs (not in Python), and studied the tradeoffs of various methods of coupling. Cut & Paste is probably the worst way to do it. Manual error is easy to creep in, where one copy is updated, and somebody neglects to update the other. It's especially bad if the item order matters, as it does for enums and for your xlist() example. Shared code works okay (have a module that both ends import). But it assumes both ends are built and ship and install on a consistent basis. Not too hard when it's a single product on a single machine. But if the two ends are on separate machines, especially separated by the Internet, you have to deal with version consistency problems. If there's a time shift as well (file format), then you're stuck at that level. Check the version, and either insist on exact match, or have a way to adapt to whichever end reports the earlier version. Make no mistake, there will be new versions, and you'll have to deal with it. Shared data is about the same, but can sometimes be more flexibly interpreted. It also can have the advantage of being able to have multiple simultaneous versions on the same machine. For the Internet case, picture a server that has to be able to serve several clients, each running different versions. And it's tougher for corruption (accidental or malicious) to do serious damage. I wouldn't want to do an import over the Internet live connection. Best is if the necessary data is passed between the two ends during initialization, and both ends know how to make that data describe the protocol they'll use. That can work as long as there's a notion of a session, and preferably if the session is two-way. In the case of file formats, it means you have this data in the header of the file. Sometimes for bandwidth reasons, you just want to transmit a version string, and not the entire table implied by that string. Just realize the increased risks involved. Probably the easiest way to stay in synch is if each message is self-describing. To me that screams "text" for the id's. It makes the message a bit larger, and you have to decide if it's worth it. The overhead could very well be lost in the noise of packeting, in any tcp/ip protocol. Note that all these have very gray boundaries. And that underneath it all, it's all just data. Barring that, make a single "structure" which lists the event names and method names in matched pairs, and derive whatever lists and dictionaries you actually need from that one structure. And that structure should be shared between client and server code, perhaps as a text file that they both parse. Or as a stream that's passed from one to the other during startup. That way, consistency between them can be regulated (with version string in the file, for example) I'm not sure how that would work. On the client side, I need to respond to a 'button-clicked' event from the gui system by sending an EVT_BUTTON_CLICKED message to the server. In other words it is hard-coded into the client program. I don't know how that would work if I read in a list of message-types at startup. Show me a sample client event handler, and maybe I can suggest how to encode it. For example in wxPython, events are encoded with an event object. You could have the event send the object's type-string as an event ID. No lookup at all. And in fact, one event handler then might handle several of the events for a given widget, or even for multiple ones. I guess it's not that simple, since you frequently have to pass other information, such as the state of the Ctrl-key, or the mouse position on the screen, which is not directly encoded in the event type. DaveA Thanks for the input - it is always good to have some fresh ideas. Frank -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj a écrit : In <1bf83a7e-f9eb-46ff-84fe-cf42d9608...@j21g2000yqe.googlegroups.com> Carl Banks writes: Yeah, it's a little surprising that you can't access class scope from a function, but that has nothing to do with encapsulation. It does: it thwarts encapsulation. The helper function in my example is one that clearly rightfully belongs nowhere else than the class itself, i.e. encapsulated within the class. I don't see what's wrong with having this function at the top-level. Sorry to have to say it this way, but IMHO you're border on cargo-cult thinking here. Python is an all-object language (ie : everything is an object, including functions, classes and modules), but it's by no mean 'pure-object', and module level functions are perfectly ok (and quite often the right thing). Now if you really want to "encapsulate" the function and the class together, you do have simple and and working solutions : using a nested recursive function (as explained by Diez), or nesting both the class and function in a factory function, ie: def Demo(): def fact(n): if n < 2: return 1 else: return n * fact(n - 1) class Demo(object): _classvar = fact(5) return Demo Demo = Demo() But anyway: this is really a WTF. Python's notion of encapsulation is very weak (by design), and you're really wasting time trying to fight the language instead of learning it. Just put that f... helper function at the top level (prefixing it's name with a '_' to mark it as implementation detail), and move on to something else !-) It is only this silly prohibition against recursive functions in a class statement that forces one to put it outside the class statement. The "prohibition" only happens for recursive functions defined *and* called in the class statement. And once you get the big picture, it's certainly not "silly". -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj a écrit : In "Martin P. Hellwig" writes: kj wrote: First, one of the goals of OO is encapsulation, not only at the level of instances, but also at the level of classes. Who says? Python itself: it already offers a limited form of class encapsulation (e.g. class variables). "class variables" - which FWIW include the "methods" - are just attributes of the class *object* (reminder : Python's classes and functions *are* objects too). Any name bound at the top level of the class statement scope becomes an attribute of the class object. IOW, this "limited form of class encapsulation" is just the ordinary "form of encapsulation" you'll get with Python objects. It would be nice if it went all the way and gave classes their own bona fide scope. (But I hasten to add: I *still* don't understand the Python scope model, I think that what you should first understand are Python's execution and object models. Anyway, you could be right (I am not capable to judge it) and Python should change on this issue but from what I gathered, Pythons OO is inspired by the following: - Don't repeat yourself - Containing code into logical units makes it easier to understand and maintain. ...except, apparently, when that code is a recursive function, in which case one's out of luck. I wrote quite a few recursive functions in Python and never had any problem. Second, my example shows that Python puts some peculiar restrictions on recursion. It's not a restriction on recursion, it's a scoping rule that apply to any other name. You can't access the class statement's scope from within a function, period. Recursion! One of the central concepts in the theory of functions! It is also one of the best ways to shoot yourself in the foot... If recursion is so evil, and Python so intent in saving us from shooting ourselves in the foot, why does it allow recursion at all? Recursion is not evil, and Python doesn't try to prevent anyone from doing stupid things anyway. FWIW, do you know that you can add / replace / remove attributes (including methods) at runtime, both on a per-instance or per-class basis ? And even dynamically change the class of an object ?-) -- http://mail.python.org/mailman/listinfo/python-list
RE: Move dictionary from instance to class level
Dave Angel wrote: > > Show me a sample client event handler, and maybe I can suggest how to > encode it. For example in wxPython, events are encoded with > an event > object. You could have the event send the object's type-string as an > event ID. No lookup at all. And in fact, one event handler > then might > handle several of the events for a given widget, or even for multiple > ones. I guess it's not that simple, since you frequently > have to pass > other information, such as the state of the Ctrl-key, or the mouse > position on the screen, which is not directly encoded in the > event type. That is definitely *not* what I want to do. I want to make the server as generic as possible, so that it can handle any type of client, hopefully even including a browser eventually. Therefore the server has no knowledge of wxPython event types. I have abstracted all the event types I am interested in (the list is fairly stable now). My protocol requires that the client maps a specific gui event type to a message identifier, and the server maps the message identifier to a method that handles the message. Hope that makes sense. Frank -- http://mail.python.org/mailman/listinfo/python-list
Parse xml file
Is there a quick way to retrieve data from an xml file in python 2.4, rather than read the whole file? -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
Frank Millman wrote: Hi all I mentioned yesterday that I had a problem sending a message to the newsgroup via the Outlook Express news reader. Today I received an email from DaveA, which was sent to me via [email protected]. I tried simply replying to the email, to see if it behaved better than Outlook Express. I hit 'Reply to all', so it 'replied' to the sender and cc'ed to [email protected]. I have just checked in google-groups and my message does appear, in the correct thread, but not in its correct thread position. Is there a proper way to do this, or is it better to stick to a news reader like Outlook Express? Thanks Frank Millman P.S. I am sending this message via email to [email protected] - let's see what happens. I use Thunderbird, and treat the list as ordinary mail. I use reply-all, and it seems to do the right thing. Or at least if I'm breaking threads, nobody has pointed it out to me yet. I'm not sure how the list-server decides what thread a particular message belongs to. It's more than just the subject line, since when people change the subject, it stays in the same thread. I'm guessing it's somewhere in the boilerplate that's built by a normal mail program when it builds a reply message. And since I don't see threads this way, I wouldn't know if I broke things. I'd love to see an FAQ on how to handle these python.org mailing lists, with recommendations on settings to use both when you sign up for the list, and within various mail applications. For example, I see a single message containing typically around 10 attachments. I do the reply-all to one of these attachments, and it handles the message body okay, the To/CC fields okay, usually adds an extra RE: on the subject (so it becomes RE: RE: subject). But it defaults to the wrong From: address, so I have to change that by hand. I don't have that problem if I reply directly to a message, say from my in-box. The FAQ could also cover conventions and other techniques, such as whether to use html or plain-text for messages, how to use ** to mark a word as bold, top-posting suggestions DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thu, 27 Aug 2009 08:38:29 +0200, Hendrik van Rooyen wrote: > On Wednesday 26 August 2009 17:14:27 kj wrote: > >> As I described at length in another reply, the function in question is >> not intended to be "callable outside the class". And yes, > > I think this might go to nub of your problem - It might help you to > think as follows: > > A Python class, even after it has been executed, does not really exist > except as a kind of template or pattern - it is mostly useless until an > instance of the class is made by calling it with whatever it needs to > set up the instance. And once you have an instance, you can do stuff > with that particular instance. Before that time, the class is mostly > just a promise of things to come. Oh my! I couldn't disagree more strongly! I think the above is totally incorrect. Classes and types are first class objects, you can treat them like anything else in Python. In fact, classes themselves are instances of type, so you can say: >>> class C(object): # must inherit from object ... pass ... >>> issubclass(C, object) True >>> isinstance(C, type) True Classes are themselves instances of their metaclass. By default, classes have a metaclass of type, but you can easily change that. Metaclass programming is advanced but very powerful. Because classes are themselves objects, you can (with a bit of metaclass jiggery-pokery) make them do all sorts of interesting things. For instance, huge amounts of effort are often put into creating a Singleton class, a class that has a single instance. Well, okay... but why not just use the class object itself, instead of an instance? There's already one of those, and you can't (easily) make a copy of it, and even if you did, it would be an independent class. Instead of this: singleton = SingletonClass(args) do_something_with(singleton) just do this: do_something_with(SingletonClass) Of course SingletonClass needs to be designed to work that way, which will probably need some metaclass magic. It would be interesting to see which requires less effort. When it comes to built-in classes (types), I often use the class object itself as an object. E.g. I might do something like this: def convert(seq): t = type(seq) # remember the original type result = process(seq) # always produces a list if t is list: return result # don't bother making a copy of the result elif t is str or t is unicode: empty = t() return empty.join(result) else: return t(result) # return the original type >> recursive functions in Python *are* restricted in ways that >> non-recursive functions aren't. The examples I've posted prove this >> point unambiguously. > > Yes and no - mostly no - your examples just illustrate the point I > tried to make above. Completely no. You may have missed the examples I've given, but the problems the Original Poster were having had nothing to do with recursion. > Pythons object model, and its classes, are different from what you are > used to. A bare class is mostly useless without an instance, which is > ultimately why accessing a function in a class from itself like you are > doing, without reference to an instance, does not work - the function > does not exist yet to a degree that it can be referenced. That is incorrect. What's going on is more subtle. >>> class Demo: ... def function(x): ... print "Calling function with argument %s" % x ... function(None) ... function(1) ... function(function) ... Calling function with argument None Calling function with argument 1 Calling function with argument >>> Demo -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Parse xml file
On Thu, Aug 27, 2009 at 2:26 PM, loial wrote: > Is there a quick way to retrieve data from an xml file in python 2.4, > rather than read the whole file? Universal Feed parser can do the job for you. This can be imported and used in your python programs. For more information, http://www.feedparser.org/ -- Regards, S.Balamurugan Free the code, Free the User -- http://mail.python.org/mailman/listinfo/python-list
Re: Move dictionary from instance to class level
Frank Millman wrote: Dave Angel wrote: Show me a sample client event handler, and maybe I can suggest how to encode it. For example in wxPython, events are encoded with an event object. You could have the event send the object's type-string as an event ID. No lookup at all. And in fact, one event handler then might handle several of the events for a given widget, or even for multiple ones. I guess it's not that simple, since you frequently have to pass other information, such as the state of the Ctrl-key, or the mouse position on the screen, which is not directly encoded in the event type. That is definitely *not* what I want to do. I want to make the server as generic as possible, so that it can handle any type of client, hopefully even including a browser eventually. Therefore the server has no knowledge of wxPython event types. I have abstracted all the event types I am interested in (the list is fairly stable now). My protocol requires that the client maps a specific gui event type to a message identifier, and the server maps the message identifier to a method that handles the message. Hope that makes sense. Frank Yes, it makes sense. Sorry for heading down that particular dead-end. But the more I think about it, the more likely I think it is that you'll be adding new message types, even if they're just variants of ones already defined. So it might behoove you to have a shared "data structure" that describes the whole message, not just equates a name to an integer. Or consider pickling. I don't know the tradeoffs, but the idea is that an object is constructed at the other end that has all the same data members as the object you had at this end. Perhaps with a flexible enough class definition, you could represent all or at least several of your messages with the same object. I am curious about your topology. You're sending events from the client (which presumably has a mouse and keyboard) to a server. But what does the server do with those? Does it have its own screen, or what? DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thu, 27 Aug 2009 09:09:21 +0200, Hendrik van Rooyen wrote: > On Wednesday 26 August 2009 17:45:54 kj wrote: >> In <[email protected]> Steven D'Aprano > writes: > >> >Why are you defining a method without a self parameter? >> >> Because, as I've explained elsewhere, it is not a method: it's a >> "helper" function, meant to be called only once, within the class >> statement itself. > > If the sole purpose of the function is to be used to define what will > become a constant, why do you not just calculate the constant on your > calculator, or at the interactive prompt, and assign it to the > attribute, and be done with it? > > Why waste run time recalculating every time the programme is called? What you are calculating might actually be quite complicated to enter as a literal. You might have something like: class C(object): TABLE = [] for i in xrange(100): row = [] for j in xrange(100): row.append((i**3 + 2*i**2 - i*j + 7*j**2 + 9*i*j**2 - j)/3) TABLE.append(row) It's a little hard to type out C.TABLE as a literal. And even if you could, which would you rather see if you were debugging this class? The above, or: class C(object): TABLE = [ [0.0, 2.0, 8.6661, 20.0, 36.0, ... ], [1.0, 5.667, 21.0, 47.0, 83.671, ...], [5.333, 12.666, 36.664, ...], ... [... , 3143161.0, 3201497.65, 3260433.0] ] For obvious reasons I haven't typed the whole thing out! And imagine trying to check it for typos! Clearly this is a made-up example, but the principle is sound. If Python can calculate values for you, why not let it do so? It is easier for you, easier to check that you've calculated them correctly, easier to debug and read, it makes the algorithm clearer (fewer "magic constants"). Yes, there is a run-time cost, but you only pay it once, when you import the module, and it's likely to be not that much more expensive than parsing the literals anyway. Of course, for something as big and complicated as the above table, I'd almost certainly put the code to calculate it in a function outside of the class, but that's a matter of style, and it will work to put it inside the class. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
Dave Angel wrote: Frank Millman wrote: I use Thunderbird, and treat the list as ordinary mail. I use reply-all, and it seems to do the right thing. Or at least if I'm breaking threads, nobody has pointed it out to me yet. reply-all may send duplicate messages to the author. Not sure of this list. I use Thunderbird and access python-list as a newsgroup via news.gmane.org as gmane.comp.python.general. About 200 other python mailing lists are accessible as g.c.p.xxx. The first time one posts to a particular mailint list, the post is held until one replies to a email sent to the 'from:' address. This cuts spam tremendously. Otherwise, no signup seems to be needed. tjr -- http://mail.python.org/mailman/listinfo/python-list
RE: Move dictionary from instance to class level
Dave Angel wrote: > > Frank Millman wrote: > > > > That is definitely *not* what I want to do. > > > > I want to make the server as generic as possible, so that > it can handle any > > type of client, hopefully even including a browser > eventually. Therefore the > > server has no knowledge of wxPython event types. > > > > I have abstracted all the event types I am interested in > (the list is fairly > > stable now). My protocol requires that the client maps a > specific gui event > > type to a message identifier, and the server maps the > message identifier to > > a method that handles the message. > > > > Hope that makes sense. > > > > Frank > > > > > > > Yes, it makes sense. Sorry for heading down that particular > dead-end. > But the more I think about it, the more likely I think it is > that you'll > be adding new message types, even if they're just variants of ones > already defined. So it might behoove you to have a shared "data > structure" that describes the whole message, not just equates > a name to > an integer. > > Or consider pickling. I don't know the tradeoffs, but the > idea is that > an object is constructed at the other end that has all the same data > members as the object you had at this end. Perhaps with a flexible > enough class definition, you could represent all or at least > several of > your messages with the same object. > > I am curious about your topology. You're sending events from > the client > (which presumably has a mouse and keyboard) to a server. But > what does > the server do with those? Does it have its own screen, or what? > I'll try to explain. I am writing a fairly standard business/accounting application. (I am now adding Business Process Management to it, which is complicating matters, but that is another story.) Most of the gui stuff is basic forms processing - screens with static data, text fields for display and input of data, and buttons for signifying certain actions to be taken. My original attempt had both the gui and the business logic running on the client, with a connection to a database running on a server. It worked, but then I realised it was very insecure - it would be easy to hack the python code, bypass the business logic, and allow any update to the database. So my second attempt took all the business logic out of the client and put it onto the server. To execute a form, the server builds a form definition by creating objects to represent each of the widgets, creates a list of the components with sufficient information for the client to render them , then sends a json'd copy of the list to the client, which interprets it and displays the required form. The client informs the server of each event, and the server handles the event in much the same way as it did before when the business logic was on the client. For example, clicking a button triggers a response which could involve updating the database, displaying another window with additional data, etc, etc. Previously there would have been a method on the client designed to handle the response, and the method would be added to the button constructor so that it would be called when the button was clicked. Now the method is on the server, and is stored as an attribute of the button object on the server. When the user clicks the button, the message is passed up to the server (each widget has its own id, which is part of the message), the server is notified that the button was clicked, and it calls the associated method. There is a lot more to it than that, but hopefully that will give you an idea. If I ever get this to a workable state (it is taking far longer than I anticipated) I will release it as open source, and will then welcome as much feedback as possible. Frank -- http://mail.python.org/mailman/listinfo/python-list
About diagram and python
Hello! I see on my Diagram Editor software this : File -> Export... -> (on Export option is : PyDia Code Generation ... .py) What python is in this file ? How help me with python code ? Thank you ! -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
On Thu, Aug 27, 2009 at 7:04 PM, Dave Angel wrote: > I'm not sure how the list-server decides what thread a particular message > belongs to. It's more than just the subject line, since when people change > the subject, it stays in the same thread. > I'm just using gmail because it saves me the trouble of reconfiguring the mail server every time I use a new computer (which I do at uni quite a lot). When someone changes the Subject with (was: XXX), it opens as a new "thread" on gmail. also, when someone puts "Re:" in the subject it also puts it on a new thread. The magical thing about gmail is that it seems to ingnore the first "Re:" on the subject line, and make them the same thread. I rarely have threading issues, but occasionally I do see "Re:" messages in a separate place, maybe once a month. I'd love to see an FAQ on how to handle these python.org mailing lists, with > recommendations on settings to use both when you sign up for the list, and > within various mail applications. Google found me these: http://www.gnu.org/software/mailman/faq.html http://www.gnu.org/software/mailman/docs.html Maybe they're helpful, since that's what the python-list uses. I've only scanned for a bit and it seems comprehensive. > For example, I see a single message containing typically around 10 > attachments. I do the reply-all to one of these attachments, and it handles > the message body okay, the To/CC fields okay, What do you mean 10 attachments? O_o. I know some people like to attach a company logo in their signature. (The Aussie DLF list people do that heaps. Although some people post a hand-written sig in the attachment ... I'm not sure how smart that is, but I've seen it done.) Where are you getting these "attachments"? I haven't tried reply-all yet. May give that a try next time and see what pops up in the To: address. > usually adds an extra RE: on the subject (so it becomes RE: RE: subject). Gmail doesn't do that. Yay! (Re: is dumb anyway, and you can't prepend Re: forever. Fwd: is reasonable.) > But it defaults to the wrong From: address, so I have to change that by > hand. I don't have that problem if I reply directly to a message, say from > my in-box. Weird. I have a different problem: the "To:" Address is usually the sender I'm replying to. It's really annoying, because I always have to hand-change the To: address to python-list. I've sent two messages onto the list mentioning about adding a "Reply-to" attribute by the mailing list server, which would fix this problem. To-date everyone has seemed to ignore me. =/ > The FAQ could also cover conventions and other techniques, such as whether > to use html or plain-text for messages, how to use ** to mark a word as > bold, top-posting suggestions I didn't know ** marks bold. Does __ mark underline? Those are cool things I never hear about. Thanks! On another tangent, I only found out the Python Wiki on the official site today (http://wiki.python.org/moin/) Does anyone actually use it, and what for? - Kind regards, Ching-Yun "Xavier" Ho, Technical Artist Contact Information Mobile: (+61) 04 3335 4748 Skype ID: SpaXe85 Email: [email protected] Website: http://xavierho.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: About diagram and python
On Thu, 27 Aug 2009 03:20:31 -0700, [email protected] wrote: > Hello! > I see on my Diagram Editor software this : File -> Export... -> (on > Export option is : PyDia Code Generation ... .py) > What python is in this file ? Why don't you look for yourself? Just open the file in a text editor and read it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj wrote: No, the fact() function here represents an internal "helper" function. It is meant to be called only once to help initialize a class variable that would be inconvenient to initialize otherwise; this helper function is not meant to be called from outside the class statement. That, to me, is an excellent indication that the function does *not* belong inside the class! The only things that belong inside the class are things that users of the class will need to use, or that instances of the class will need to do their job. Your helper function belongs outside the class, in the module where the class is defined. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: pygtk - What is the best way to change the mouse pointer
> From: > > MRAB > > To: > > [email protected] > > Date: > > 26/08/2009 11:04 PM > > Subject: > > Re: pygtk - What is the best way to change the mouse pointer > > Ido Levy wrote: > > Hello All, > > > > I am writing a dialog which one of its widget is a gtk.ComboBoxEntry ( > > let's assume widget in the example below is its instance ) > > When the user select one of the values from the gtk.ComboBoxEntry I need > > to run some calculations that takes a few seconds. > > In order to reflect calculation time to the user I want to switch the > > mouse pointer to an hour glass and back to arrow what it finish the > > calculation. > > > > I use the following code but it doesn't seems to work in a deterministic > > way. From time to time it skips the last line and keep the mouse pointer > > as an hour glass. > > > > watch = gtk.gdk.Cursor(gtk.gdk.WATCH) > > widget.window.set_cursor(watch) > > > > calculation code > > > > widget.window.set_cursor(None) > > > > I would appreciate your advice on the right way to implement this. > > > Could the calculation code be raising an exception? Try adding some > logging to see whether the last lien is actually being called. You could > also use a try...finally... block to ensure that the last line is > called: > > watch = gtk.gdk.Cursor(gtk.gdk.WATCH) > widget.window.set_cursor(watch) > try: > calculation code > finally: > widget.window.set_cursor(None) > Thank you for your input. I used logging and it seems that the last line is called. I also used try...finally... block but it didn't solve the issue. Then I have noticed that the line before the last one is widget.connect() I insert time.sleep() in between the lines and it seems to solve the issue. I assume it's not suppose to work this way but it can be considered as a workaround -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on the Web
On Aug 27, 1:02 pm, Phil wrote: > Thanks a lot for another response. I've never posted in groups like > this before but the results are amazing. > > I will definitely consider trying mod_wsgi when I get a chance. I like > the approach taken with it. It is unfortunate that I completely missed > all Apache related material because I was using lighttpd. Is there no > mod_wsgi for lighttpd? I guess I could always just Google that myself. There is no mod_wsgi for lighttpd and suggest there never will be. WSGI doesn't lend itself to working on top of an event driven system. Someone did get a mod_wsgi going on nginx, which is also event driven, but it has limitations due to possibility of blocking other traffic to web server. See: http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-version-of.html Graham -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
Ulrich Eckhardt wrote: Ulrich Eckhardt wrote: Jean-Michel Pichavant wrote: class Color: def __init__(self, r, g,b): pass BLACK = Color(0,0,0) It make sens from a design point of view to put BLACK in the Color namespace. But I don't think it's possible with python. class Color: ... setattrib(Color, "BLACK", Color(0,0,0)) Apart from it being "setattr" and not "setattrib", a simple Color.BLACK = Color(0,0,0) Obviously ... I'll remember that. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
kj wrote: I think I understand the answers well enough. What I *really* don't understand is why this particular "feature" of Python (i.e. that functions defined within a class statement are forbidden from "seeing" other identifiers defined within the class statement) is generally considered to be perfectly OK. IMO it's a bizarre, inexplicable blindspot (which, among other things, gives rise to a certain worry about what other similar craziness lurks under Python's image of rationality). I have never seen even a half-hearted justification, from a language design point of view, for why this particular "feature" is worth having. Maybe some day the BDFL will deign to give one. kynn I think I got your point. I guess many people may not be receptive to your question, cause guess what, we're all python fans :o) in foo.py: a = 5 b = a # works fine class A: c = 5 d = c # broken d = A.c # broken either def foo(self): e = 5 f = e #works fine We should all acknowledge that any newcomer to python will not expect such behavior. There are plenty of good answers to that thread explaining why the fact that classes are not scopes is much better. Still this design fails at one point : insight. It may be solved by creating the class upon the "class" statement. If the class A object is created, then c is added as a property of that object, there's no problem accession one object property with A.c. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Aug 27, 2:01 am, [email protected] (Aahz) wrote: > Well, I'm not sure about exceptions, but you almost certainly won't get > the results you want. What I'd like in this context is to iterate through the items in the list without processing the same item twice and without skipping item that are in front of the current iterator position. Somehow I can't quite prove to myself if this is possible or not over multiple threads. I.e. a dictionary will throw an exception about the object changing size while iterating through it. A list doesn't, hence the question. Manu -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
In Jean-Michel Pichavant writes: >kj wrote: >> I think I understand the answers well enough. What I *really* >> don't understand is why this particular "feature" of Python (i.e. >> that functions defined within a class statement are forbidden from >> "seeing" other identifiers defined within the class statement) is >> generally considered to be perfectly OK. IMO it's a bizarre, >> inexplicable blindspot (which, among other things, gives rise to >> a certain worry about what other similar craziness lurks under >> Python's image of rationality). I have never seen even a half-hearted >> justification, from a language design point of view, for why this >> particular "feature" is worth having. Maybe some day the BDFL will >> deign to give one. >> >> kynn >> >I think I got your point. >I guess many people may not be receptive to your question, cause guess >what, we're all python fans :o) >in foo.py: >a = 5 >b = a # works fine >class A: >c = 5 >d = c # broken >d = A.c # broken either > >def foo(self): > e = 5 > f = e #works fine >We should all acknowledge that any newcomer to python will not expect >such behavior. There are plenty of good answers to that thread >explaining why the fact that classes are not scopes is much better. >Still this design fails at one point : insight. >It may be solved by creating the class upon the "class" statement. If >the class A object is created, then c is added as a property of that >object, there's no problem accession one object property with A.c. Thanks! I was beginning to think I'd gone crazy. kynn -- http://mail.python.org/mailman/listinfo/python-list
Learning Python advanced features
Hi, Learning Python, I understand the mechanism of : closure, __new__, descriptors, decorators and __metaclass__, but I interrogate myself on the interest of those technics ? May somebody explain me the interest ? Many thanks ! Jackes Bihan -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thu, 27 Aug 2009 13:45:00 +0200, Jean-Michel Pichavant wrote: > in foo.py: > > a = 5 > b = a # works fine > > class A: > c = 5 > d = c # broken Incorrect. That works fine. >>> class A: ... c = 5 ... d = c # not actually broken ... >>> A.c 5 >>> A.d 5 The class is a scope, and inside the class scope, you can access local names. What you can't do is access the class scope from inside nested functions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
In Jean-Michel Pichavant writes: >in foo.py: >a = 5 >b = a # works fine > >def foo(self): > e = 5 > f = e #works fine >It may be solved by creating the class upon the "class" statement. If >the class A object is created, then c is added as a property of that >object, there's no problem accession one object property with A.c. I thought one could implement something like class A: c = 5 d = __thisclass__.c But apparently this is a *huge* deal. I'm not sure if the reason it is a huge deal is that it is technically difficult to implement, or that there is an implicit "lie" in having something (__thisclass__) standing for something else that doesn't yet exist (and the potential errors that may arise from this "lie" in sufficiently unfortunate code). Or maybe something else beyond my noobish ken altogether. kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
In <[email protected]> Steven D'Aprano writes: >On Thu, 27 Aug 2009 09:09:21 +0200, Hendrik van Rooyen wrote: >> On Wednesday 26 August 2009 17:45:54 kj wrote: >>> In <[email protected]> Steven D'Aprano >> writes: >> >>> >Why are you defining a method without a self parameter? >>> >>> Because, as I've explained elsewhere, it is not a method: it's a >>> "helper" function, meant to be called only once, within the class >>> statement itself. >> >> If the sole purpose of the function is to be used to define what will >> become a constant, why do you not just calculate the constant on your >> calculator, or at the interactive prompt, and assign it to the >> attribute, and be done with it? >> >> Why waste run time recalculating every time the programme is called? >What you are calculating might actually be quite complicated to enter as >a literal. Thank you! kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: ubuntu dist-packages
Florian Diesch wrote:
.
From /usr/lib/python2.6/site.py:
,
| For Debian and derivatives, this sys.path is augmented with directories
| for packages distributed within the distribution. Local addons go
| into /usr/local/lib/python/dist-packages, Debian addons
| install into /usr/{lib,share}/python/dist-packages.
| /usr/lib/python/site-packages is not used.
`
the above is not present in my windows documentation (or indeed site.py) at all
so it seems they just decided to change the name. Anyone trying to debug why
their distutils or setuptools or whichever python packager is going wrong will
have yet another detail to remember. In addition, as any one who has done such
trivial changes will already know, they forgot to do it globally eg my 0.4.1.0
version of the "Debian Python Policy" document explicitly mentions site-packages.
--
Robin Becker
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
Jean-Michel Pichavant a écrit : kj wrote: I think I understand the answers well enough. What I *really* don't understand is why this particular "feature" of Python (i.e. that functions defined within a class statement are forbidden from "seeing" other identifiers defined within the class statement) is generally considered to be perfectly OK. IMO it's a bizarre, inexplicable blindspot (which, among other things, gives rise to a certain worry about what other similar craziness lurks under Python's image of rationality). I have never seen even a half-hearted justification, from a language design point of view, for why this particular "feature" is worth having. Maybe some day the BDFL will deign to give one. kynn I think I got your point. I guess many people may not be receptive to your question, cause guess what, we're all python fans :o) in foo.py: a = 5 b = a # works fine class A: c = 5 d = c # broken Err... Did you actually tried this ? >>> class A: ... c = 5 ... d = c ... >>> A.c 5 >>> A.d 5 >>> d = A.c # broken either Not "broken" : the class doesn't yet exists, nor is it bound to global name 'A'. FWIW, *this* works (for some definitions of 'works') juts fine: >>> class Foo(object): ... c = 42 ... >>> A = Foo() >>> class A(object): ... d = A.c ... >>> A.d 42 We should all acknowledge that any newcomer to python will not expect such behavior. Any newcomer to any language should aknowledge that her expectations based on previous experience with any other language should be kept aside or just plain abandoned, and start by learning the new language. The only thing one is entitled to expect when learning a new language is that the language's implementation follows the language specs. There are plenty of good answers to that thread explaining why the fact that classes are not scopes is much better. Still this design fails at one point : insight. Oh, really ? It may be solved by creating the class upon the "class" statement. If the class A object is created, then c is added as a property of that object, there's no problem accession one object property with A.c. Please, write a pep... -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python advanced features
jvpic a écrit : Hi, Learning Python, I understand the mechanism of : closure, __new__, descriptors, decorators and __metaclass__, but I interrogate myself on the interest of those technics ? May somebody explain me the interest ? Didn't like my answers on f.c.l.py ?-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
On 26 ago, 05:29, erikj wrote: > Hi, > > You could have a look at Camelot, to see if it fits > your needs :http://www.conceptive.be/projects/camelot/ > > it was developed with cross platform business apps in > mind. when developing Camelot, we tried to build it using > wxWidgets first (because of the licensing at that time), > but it turned out that developing with QT proved to be > much more straightforward. QT is documented very well > and you seldom encounter 'strange' issues that cost hours > of time to pinpoint and fix. > > the datagrid was developed to be able to handle millions > of database records without glitches and is flexible thanks > to QT's model-view-delegate framework. > > we do print barcodes with this app (even directly to > zebra printers) > > if you have questions regarding Camelot, please feel free > to post on our mailing list :http://groups.google.com/group/project-camelot > > Regards, > > Erik > > On Aug 24, 2:08 pm, Gilles Ganault wrote: > > > > > Hello > > > I was wondering if some people in this ng use Python and someGUI > > toolkit (PyWin32, wxWidgets, QT, etc.) to build professional > > applications, and if yes, what it's like, the pros and cons, etc. > > > I'm especially concerned about the lack of controls, the lack of > > updates (lots of controls in wxWidgets are 1.0 deadware), and problems > > linked to how to update users' PC remotely when I build a new version > > using eg. Py2exe. > > > I need controls for business apps like access to databases, good data > > grid, printing reports (with or without barcodes), etc. > > > Thank you. Looks interesting, but I wonder if I can use Camelot without its ORM. I feel that ORMs make easy things easier, but complex things much harder... Can I use it with plain old sql? Luis -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
2009/8/27 Terry Reedy : > reply-all may send duplicate messages to the author. Not sure of this list. I'm fairly sure Mailman deals with that. -- -David -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
Emanuele D'Arrigo wrote: > On Aug 27, 2:01 am, [email protected] (Aahz) wrote: >> Well, I'm not sure about exceptions, but you almost certainly won't get >> the results you want. > > What I'd like in this context is to iterate through the items in the > list without processing the same item twice and without skipping item > that are in front of the current iterator position. Somehow I can't > quite prove to myself if this is possible or not over multiple > threads. I.e. a dictionary will throw an exception about the object > changing size while iterating through it. A list doesn't, hence the > question. This is not even possible in a single thread: >>> items = [1, 2, 3] >>> for i in items: ... print i ... if 1 in items: items.remove(1) ... 1 3 Basically a list iterator is just a list reference and an index into that list. No effort is made to keep track of added or removed items. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thu, 27 Aug 2009 09:10:46 +0100 Stephen Fairchild wrote: > So why didn't you delete it after you were done with it? > > Class Demo(object): That should be "class". > _classvar = fact(5) > del fact() I suppose you mean "del fact". -- 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: List iterator thread safety
On Tue, Aug 25, 2009 at 3:43 AM, Emanuele D'Arrigo wrote: > Let's say I have a list accessed by two threads, one removing list > items via "del myList[index]" statement the other iterating through > the list and printing out the items via "for item in myList:" > statement. I tried something similar to that before. Gave me an error. I *think* it was in compile-time, too, but I might be wrong. The message was something like that the list size cannot be changed. > Am I right to say this -won't- generate exceptions because > the list iterator is not concerned with the list changing in size > under its nose? It kind of concerns about the size, I think. If it just checked the "next" item, that would have been so awesome. > Or are there pitfalls I should be aware of? The pitfall is that I don't think it will work at all. At least I haven't succeeded in doing this in the past. If you make it work, be sure to share your thoughts =] Good luck, -Xav -- http://mail.python.org/mailman/listinfo/python-list
Does Class implements Interface?
Greetings everybody, let's say I have a Class C and I'd like to verify if it implements Interface I. If I is available to me as a class object I can use issubclass(C, I) and I can at least verify that I is a superclass of C. There are a couple of issues with this approach however: 1) C might override not just I's methods code but also I's methods signatures, effectively changing the interface. 2) What if I is -not- available to me as the superclass of C but as a description of the interface, i.e. as an IDL(*) file? Are there resources such as tools, recipes, documents or strategies that could help me deal with these issues? I've already looked into the ABC module and the zope.interface. I'm just fishing for more things to look at. Manu (*) http://en.wikipedia.org/wiki/Interface_description_language -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on the Web
Phil a écrit : (snip) However, 99.9% of the discussion I see with Python on the web is around FCGI. May I suggest you spend some time reading django-users and django-dev on google groups ? (and that's only *one* of the way-too-many Python web frameworks). -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thursday 27 August 2009 11:14:41 Steven D'Aprano wrote: > On Thu, 27 Aug 2009 08:38:29 +0200, Hendrik van Rooyen wrote: > > On Wednesday 26 August 2009 17:14:27 kj wrote: > >> As I described at length in another reply, the function in question is > >> not intended to be "callable outside the class". And yes, > > > > I think this might go to nub of your problem - It might help you to > > think as follows: > > > > A Python class, even after it has been executed, does not really exist > > except as a kind of template or pattern - it is mostly useless until an > > instance of the class is made by calling it with whatever it needs to > > set up the instance. And once you have an instance, you can do stuff > > with that particular instance. Before that time, the class is mostly > > just a promise of things to come. > > Oh my! I couldn't disagree more strongly! I think the above is totally > incorrect. It was intended to help the OP out of the mental hole he finds himself in. Most of the classes I use fall directly into such a classification - they are useless until an instance is created. And I would be so bold as to say that _all_ gui classes are like that. This is the pattern I am talking about: class thing(object): def __init__(self,foo,bar): stuff to do things with foo and bar, creating or modifying attributes of the instance. def somemethod(self,baz,bling): instance method to do further operations on the attributes of the instance Now kindly explain to me how a class like that is usefull before an instance of it is created, and I might agree with you that what I said is "totally incorrect" 8< --trivial examples showing that there is something there > Classes are themselves instances of their metaclass. By default, classes > have a metaclass of type, but you can easily change that. Metaclass > programming is advanced but very powerful. > > Because classes are themselves objects, you can (with a bit of metaclass > jiggery-pokery) make them do all sorts of interesting things. For > instance, huge amounts of effort are often put into creating a Singleton > class, a class that has a single instance. Well, okay... but why not just > use the class object itself, instead of an instance? There's already one > of those, and you can't (easily) make a copy of it, and even if you did, > it would be an independent class. Instead of this: > > singleton = SingletonClass(args) > do_something_with(singleton) > > just do this: > > do_something_with(SingletonClass) > > Of course SingletonClass needs to be designed to work that way, which > will probably need some metaclass magic. It would be interesting to see > which requires less effort. *nods* yes this would make sense - but it is not quite what either the OP or I was on about. > > When it comes to built-in classes (types), I often use the class object > itself as an object. E.g. I might do something like this: > > def convert(seq): > t = type(seq) # remember the original type > result = process(seq) # always produces a list > if t is list: > return result # don't bother making a copy of the result > elif t is str or t is unicode: > empty = t() > return empty.join(result) > else: > return t(result) # return the original type nice. now try doing it with object: thing = object() After that, thing will exist, but it is a bit like write only memory - completely useless, until you have done some more work with it. > > >> recursive functions in Python *are* restricted in ways that > >> non-recursive functions aren't. The examples I've posted prove this > >> point unambiguously. > > > > Yes and no - mostly no - your examples just illustrate the point I > > tried to make above. > > Completely no. You may have missed the examples I've given, but the > problems the Original Poster were having had nothing to do with recursion. The yes was in there to make the man feel a bit better, and because from where he stood, it _was_ the recursion that did him in. : - ) > > > Pythons object model, and its classes, are different from what you are > > used to. A bare class is mostly useless without an instance, which is > > ultimately why accessing a function in a class from itself like you are > > doing, without reference to an instance, does not work - the function > > does not exist yet to a degree that it can be referenced. > > That is incorrect. What's going on is more subtle. > Right - I can see that you are reading that to mean that there must be an instance. That is not what I intended to bring across. I was talking about the lack of a reference that is his original problem, which he only encountered with recursion. > >>> class Demo: > > ... def function(x): > ... print "Calling function with argument %s" % x > ... function(None) > ... function(1) > ... function(function) > ... > Calling function with argum
Re: Does Class implements Interface?
On Thu, Aug 27, 2009 at 9:16 AM, Emanuele D'Arrigo wrote: > Greetings everybody, > > let's say I have a Class C and I'd like to verify if it implements > Interface I. If I is available to me as a class object I can use > issubclass(C, I) and I can at least verify that I is a superclass of > C. There are a couple of issues with this approach however: > > 1) C might override not just I's methods code but also I's methods > signatures, effectively changing the interface. > 2) What if I is -not- available to me as the superclass of C but as a > description of the interface, i.e. as an IDL(*) file? > > Are there resources such as tools, recipes, documents or strategies > that could help me deal with these issues? I've already looked into > the ABC module and the zope.interface. I'm just fishing for more > things to look at. > > Manu > > (*) http://en.wikipedia.org/wiki/Interface_description_language Python's general philosophy is that it's Easier to Ask Forgiveness than Permission. Don't check the interface, just assume it's true and wrap the code block in a try/except in case it isn't. > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Aug 27, 5:03 am, "Emanuele D'Arrigo" wrote: > On Aug 27, 2:01 am, [email protected] (Aahz) wrote: > > > Well, I'm not sure about exceptions, but you almost certainly won't get > > the results you want. > > What I'd like in this context is to iterate through the items in the > list without processing the same item twice and without skipping item > that are in front of the current iterator position. Somehow I can't > quite prove to myself if this is possible or not over multiple > threads. I.e. a dictionary will throw an exception about the object > changing size while iterating through it. A list doesn't, hence the > question. Deleting items from a list while iterating over it is a bad idea, exceptions or not. Hmm, this sounds like something someone might do for a game. You have a list of objects, and in a given time step you have to iterate through the list and update each object. Problem is, one of the enemies is kill before you get to it, so you would like to remove the object from the list while iterating. Not an easy problem. For this simple appeoach, I would suggest writing a custom container (with an underlying list) with state to keep track of the current iterating position. Whenever an item is removed the index is modified (so as to prevent skipping objects), and because you are keeping track of the index yourself there is an iterator that might throw an exception. With threads, you would need to use a Condition or something to sychronize access to the object. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: ubuntu dist-packages
Paul Boddie wrote: > On 26 Aug, 17:48, Jorgen Grahn wrote: >> >> Well, if you are thinking about Debian Linux, it's not as much >> "ripping out" as "splitting into a separate package with a non-obvious >> name". Annoying at times, but hardly an atrocity. > > Indeed. Having seen two packages today which insisted on setuptools, > neither really needing it, and with one actively trying to download > stuff from the Internet (fifteen seconds warning - how generous!) when > running setup.py, it seems to me that it isn't the distribution > packagers who need to be re-thinking how they install Python software. > > Generally, distributions have to manage huge amounts of software and > uphold reasonable policies without creating unnecessary maintenance. > Sadly, until very recently (and I'm still not entirely sure if there's > really been an attitude change) the Pythonic packaging brigade has > refused to even consider the needs of one of the biggest groups of > consumers of the upstream code. Consequently, distributions will > always devise different ways of storing installed Python software, > documentation and resources, mostly because the Pythonic tools have > been deficient, particularly in the management of the latter > categories. You mean it's the problem of the python packaging that it can't deal with RPMs, debs, tgzs, OSX bundles, MSIs and ? Multiplied by the various packaging philosophies the respective distros build based on these have? I'm a Python-developer. I develop libraries and tools for Python, and want others to be able to install these - as I want to install things *other* python developers created. Setuptools let's me do that (most of the time. And I mean most). If somebody thinks he wants to include these in whatever form he prefers - fine with me. But it's hardly *my* problem, or that of the Python world in general, to fulfill the requirements some other people come up with. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Move dictionary from instance to class level
To take things one step further, I would recommend using decorators to
allow symbolic association of functions with the message identifiers,
as follows:
==
(MESSAGE_ONE
,MESSAGE_TWO
,MESSAGE_THREE
) = xrange(3)
class MyClass(object):
method_dict = {}
# create helper decorator
register_method = lambda msg, method_dict=method_dict: lambda
function: method_dict.setdefault(msg, function)
@register_method(MESSAGE_ONE)
def handle_one(self):
print 'handling MESSAGE_ONE'
@register_method(MESSAGE_TWO)
def handle_two(self):
print 'handling MESSAGE_TWO'
@register_method(MESSAGE_THREE)
def handle_three(self):
print 'handling MESSAGE_THREE'
# no longer need helper decorator
del register_method
# function to dispatch messages
def on_message_received(self, msg):
MyClass.method_dict[msg](self)
x = MyClass()
x.on_message_received(MESSAGE_ONE)
x.on_message_received(MESSAGE_TWO)
x.on_message_received(MESSAGE_THREE)
==
Note: the line containing the lambda definition is all one line.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thursday 27 August 2009 11:31:41 Steven D'Aprano wrote: > > What you are calculating might actually be quite complicated to enter as > a literal. You might have something like: 8< -- Complicated Table Example --- Me? - never! I am just an assembler programmer. I would not touch a thing like that with a barge pole. Unless of course, I have to. > Clearly this is a made-up example, but the principle is sound. If Python > can calculate values for you, why not let it do so? It is easier for you, > easier to check that you've calculated them correctly, easier to debug > and read, it makes the algorithm clearer (fewer "magic constants"). Yes, > there is a run-time cost, but you only pay it once, when you import the > module, and it's likely to be not that much more expensive than parsing > the literals anyway. > > Of course, for something as big and complicated as the above table, I'd > almost certainly put the code to calculate it in a function outside of > the class, but that's a matter of style, and it will work to put it > inside the class. It is a hell of a thing if it needs recursion to calculate - If it was really that complex, I would calculate it, check it (if I can), document it and put it in a module of its own, with "This side up", "Fragile", and other warning stickers all over it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Q: multiprocessing.Queue size limitations or bug...
On Aug 27, 8:56 am, ryles wrote:
> On Aug 26, 4:56 am, Michael Riedel
> wrote:
>
>
>
> > Sorry for being not more specific but I'm not absolutely certain whether
> > I encountered a bug or did anything wrong:
>
> > The (stupid) code below results in a stall forever or not at 'p0.join()'
> > depending on the value of TROUBLE_MAKER.
>
> > Any help, thoughts, comments?
>
> > Thank you for your time.
>
> > Michael
>
> > # --
>
> > from multiprocessing import Process, Queue
>
> > # bit vector size
> > BVS=8
>
> > #
> > TROUBLE_MAKER=12 # for greater values p0.join() is never satisfied...
>
> > def evaluate(q, id, start=0, stop=2**BVS):
>
> > cmin = {0: []}
>
> > for mask0 in range(start, stop):
> > for mask1 in range(0, 2**BVS):
> > for mask2 in range(mask1, TROUBLE_MAKER):
> > cmin[0].append((mask0, mask1, mask2))
>
> > print 'process %d finished (dict layout: %d/%d)...' % (id,
> > len(cmin), len(cmin[0]))
> > q.put(cmin.copy())
> > q.close()
>
> > if __name__ == '__main__':
>
> > q0 = Queue()
> > q1 = Queue()
> > q2 = Queue()
> > q3 = Queue()
>
> > part = 2**BVS/4
> > p0 = Process(target=evaluate, args=(q0, 0, 0*part, 1*part),
> > name='worker_0')
> > p1 = Process(target=evaluate, args=(q1, 1, 1*part, 2*part),
> > name='worker_1')
> > p2 = Process(target=evaluate, args=(q2, 2, 2*part, 3*part),
> > name='worker_2')
> > p3 = Process(target=evaluate, args=(q3, 3, 3*part, 4*part),
> > name='worker_3')
> > p0.start()
> > print 'process 0 started...'
> > p1.start()
> > print 'process 1 started...'
> > p2.start()
> > print 'process 2 started...'
> > p3.start()
> > print 'process 3 started...'
> > # main process stalls at p0.join() for bigger TROUBLE_MAKER
> > p0.join()
> > p1.join()
> > p2.join()
> > p3.join()
> > res0 = q0.get()
> > res1 = q1.get()
> > res2 = q2.get()
> > res3 = q3.get()
> > print 'results fetched...'
>
> > # --
>
> > --
>
> There is a warning related to this in the documentation:
>
> http://docs.python.org/library/multiprocessing.html#pipes-and-queues
>
> Basically, you should reverse the order of the get() and join() calls.
>
> multiprocessing does a pretty nice job of abstracting away the low-
> level details of IPC, but there are still some gotchas. As you've
> noticed, your program will deadlock when there is a large enough
> amount of data being put into the queue. This is related to a hidden
> thread that exists inside each of your child processes. The thread is
> responsible for taking your queue items from an internal buffer and
> then writing them into a pipe that your parent process will read from
> when get() is called. The pipe mechanism is what allows the two
> processes to pass information, and is supported directly by the
> Operating System. However, the pipe has a limited capacity, and when
> it is full, the writer thread is stuck waiting for the reader to read
> enough from the pipe so that it can finish its write. The problem is
> that your parent process (reader) is not actually calling get() to
> drain the pipe. Instead it's stuck in join() waiting for the writer to
> complete.
I see. I really appreciate your valuable feedback.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
In <[email protected]> Bruno Desthuilliers writes: >The only thing one is entitled to expect when learning a new language is >that the language's implementation follows the language specs. In fact, the official docs, when they discuss scopes, are off to a bad start: Names refer to objects. Names are introduced by name binding operations. Each occurrence of a name in the program text refers to the binding of that name established in the innermost function block containing the use. The first paragraph implies that binding can only occur within functions, which is either incorrect, or presupposes a definition of "function" that is not what most programmers would recognize. In general, I found the docs very unclear on the subject of scoping. PEP 227 is much better, but I wouldn't have thought of it as "the specs". kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
On 26 авг, 23:56, MRAB wrote: > zaur wrote: > > On 26 авг, 21:11, "Rami Chowdhury" wrote: > >>> person = Person(): > >>> name = "john" > >>> age = 30 > >>> address = Address(): > >>> street = "Green Street" > >>> no = 12 > >> Can you clarify what you mean? Would that define a Person class, and an > >> Address class? > > I suppose that someone already define classes Person ans Address. > > For example, in this stupid way in a foreign module: > > > class Person(object): > > pass > > > class Address(object): > > pass > > > and the following statements > > > person = Person(): > > name = "john" > > age = 30 > > address = Address(): > > street = "Green Street" > > no = 12 > > > are constructing an instance as follows: > > > person = Person() > > person.name = "john" > > person.age = 30 > > address = person.address = Address() > > address.street = "Green Street" > > address.no = 12 > > [snip] > > Create factory functions: > > def new_address(**kwargs): > address = Address() > address.__dict__.update(kwargs) > return address > > def new_person(**kwargs): > person = Person() > person.__dict__.update(kwargs) > return person > > person = new_person(name="john", age=30, > address=new_address(street="Green Street", no=12)) Original idea isn't about how to organize my code in order to initialize these custom objects. The idea is about to use object's dictionary as nested scope. -- http://mail.python.org/mailman/listinfo/python-list
Re: ubuntu dist-packages
On 27 Aug, 15:27, "Diez B. Roggisch" wrote: > > You mean it's the problem of the python packaging that it can't deal with > RPMs, debs, tgzs, OSX bundles, MSIs and > ? No, it's the problem of the Pythonic packaging brigade that package retrieval, building and installing is combined into one unsatisfactory whole. Certainly, it's annoying to discover when building some extension that the Python headers are missing, but the rhetorical vehicle used in the Python community is to frame the distributions as people who like to move stuff around unnecessarily and to corrupt other people's work. In fact, the distributions have proven themselves to be quite competent at managing huge numbers of software packages in a semi-automated fashion, so it's baffling that people doing work on Pythonic packaging tools wouldn't want to learn as much as they can about how those people manage it. For me, when making Debian packages, it has become easier to use the debhelper stuff to install things like documentation and resources than it is to figure out which special options have to be passed to the particular distutils incarnation of the setup function in order to get such stuff put in the right place, especially since distutils probably still employs an ad-hoc 1990s proprietary UNIX "oh just dump that stuff in some directory or other and forget about it" mentality. Really, distutils should be all about *dist*ribution and even then get out of the way as much as possible - the hard stuff is extracting the appropriate knowledge about the built Python interpreter in order to build extensions. Installation should be left to something which has an opinion about where things should be placed on a particular system, and which has the capability to know how to uninstall stuff - a capability which never seems to get any closer in the distutils scene. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Thursday 27 August 2009 15:26:04 Carl Banks wrote: > Deleting items from a list while iterating over it is a bad idea, > exceptions or not. > > Hmm, this sounds like something someone might do for a game. You have > a list of objects, and in a given time step you have to iterate > through the list and update each object. Problem is, one of the > enemies is kill before you get to it, so you would like to remove the > object from the list while iterating. Not an easy problem. Its not too bad - if you crook a bit - the trick is that you iterate over the list backwards when you are removing stuff based on index, so that the remainder does not get jumbled up by losing their positions, as happens when you do it going forwards. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
On Aug 26, 5:51 am, zaur wrote: > Hi folk! > > What do you think about idea of "object's nesting scope" in python? > > Let's imaging this feature, for example, in this syntax: > > obj=: > > > or > > : > > > That's means that result object of evaluation is used as > nested scope for evaluation. > > So is this idea useful? It might be marginally useful to save typing. The idea has been discussed in various forms here quite a bit over the years. I doubt there's any chance it'll be accepted into Python, because it goes against one of the main design points of Python: that attributes should always be accessed explicitly. Having said that, the syntax you propose is awful. :) Normally when this is proposed they use a keyword such as "using": p = Person() using p: name = "Carl Banks" location = "Los Angeles" or, perhaps to save a line (even though it'd be a minor syntax abuse): using Person() as p: name = "Carl Banks" location = "Los Angeles" Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Parse xml file
loial wrote: > Is there a quick way to retrieve data from an xml file in python 2.4, > rather than read the whole file? ElementTree is available as an external package for Py2.4 (and it's in the stdlib xml.etree package since 2.5). It's pretty much the easiest way to get data out of XML files. If your statement "rather than read the whole file" was referring to the file size, note that the C implementation "cElementTree" of ElementTree is very memory efficient, so you might still get away with just reading the whole file into memory. There's also the iterparse() function which supports iterative parsing of an XML file and thus allows intermediate cleanup of used data. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Aug 27, 7:25 am, Hendrik van Rooyen wrote: > On Thursday 27 August 2009 15:26:04 Carl Banks wrote: > > > Deleting items from a list while iterating over it is a bad idea, > > exceptions or not. > > > Hmm, this sounds like something someone might do for a game. You have > > a list of objects, and in a given time step you have to iterate > > through the list and update each object. Problem is, one of the > > enemies is kill before you get to it, so you would like to remove the > > object from the list while iterating. Not an easy problem. > > Its not too bad - if you crook a bit - the trick is that you iterate over the > list backwards when you are removing stuff based on index, so that the > remainder does not get jumbled up by losing their positions, as happens when > you do it going forwards. That's only if you remove the "current item". The OP has different threads accessing the list at the same time, so I have to assume that item being remove is not necessarily the current iteration. Getting back to the game example, suppose your "list of objects in the scene" looks like this: [ HandsomeHero, Enemy1, Bullet1, Enemy2, Bullet2, Enemy3] It might happen that Bullet1.update() detects a collision with Enemy2, thus killing Enemy2, which means Enemy2 would have to be removed before the next iteration. Otherwise you're updating a zombie. (Which, parenthetically, is another approach.) Conversely, suppose Bullet2.update() detects a collision with Enemy1, and Enemy1 is removed from the list. Then Enemy3 is going to be skipped. In order to handle both cases (where an item could be removed ahead of or before the current item), you have to keep track of the current index and adjust it. A list iterator won't work. For the record, I use a more sophisticated system that explicitly resolves cause and effect in my games. That's probably beyond the scope of this thread, though. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
14:17:15 Steven D'Aprano wrote: The class is a scope, and inside the class scope, you can access local names. What you can't do is access the class scope from inside nested functions. s/from inside nested functions/from inside nested scopes Besides that detail, I fully agree. *j -- Jan Kaliszewski (zuo) -- http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
On 27 авг, 18:34, Carl Banks wrote: > On Aug 26, 5:51 am, zaur wrote: > > > > > Hi folk! > > > What do you think about idea of "object's nesting scope" in python? > > > Let's imaging this feature, for example, in this syntax: > > > obj=: > > > > > or > > > : > > > > > That's means that result object of evaluation is used as > > nested scope for evaluation. > > > So is this idea useful? > > It might be marginally useful to save typing. It also allow to structure the code. > The idea has been > discussed in various forms here quite a bit over the years. I doubt > there's any chance it'll be accepted into Python, because it goes > against one of the main design points of Python: that attributes > should always be accessed explicitly. I don't in general consider this idea as a way for implicit access to object's attributes. Idea is about to use in some way object's dictionary as nested scope in a code block. I agree though that using this only for saving typing or implicit attribute access isn't a good idea. > Having said that, the syntax you propose is awful. :) Normally when > this is proposed they use a keyword such as "using": > > p = Person() > using p: > name = "Carl Banks" > location = "Los Angeles" > > or, perhaps to save a line (even though it'd be a minor syntax abuse): > > using Person() as p: > name = "Carl Banks" > location = "Los Angeles" I don't propose concrete syntax for using object's dictionary as nested scope. I used current only to explain the idea. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
On Aug 27, 8:01 am, zaur wrote: > On 27 авг, 18:34, Carl Banks wrote: > > The idea has been > > discussed in various forms here quite a bit over the years. I doubt > > there's any chance it'll be accepted into Python, because it goes > > against one of the main design points of Python: that attributes > > should always be accessed explicitly. > > I don't in general consider this idea as a way for implicit access to > object's attributes. That's what is it regardless of what you consider it. > Idea is about to use in some way object's dictionary as nested scope > in a code block. Which is implicitly accessing the object's attributes. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Move dictionary from instance to class level
Frank Millman wrote: Dave Angel wrote: Frank Millman wrote: That is definitely *not* what I want to do. I want to make the server as generic as possible, so that it can handle any type of client, hopefully even including a browser eventually. Therefore the server has no knowledge of wxPython event types. I have abstracted all the event types I am interested in (the list is fairly stable now). My protocol requires that the client maps a specific gui event type to a message identifier, and the server maps the message identifier to a method that handles the message. Hope that makes sense. Frank Yes, it makes sense. Sorry for heading down that particular dead-end. But the more I think about it, the more likely I think it is that you'll be adding new message types, even if they're just variants of ones already defined. So it might behoove you to have a shared "data structure" that describes the whole message, not just equates a name to an integer. Or consider pickling. I don't know the tradeoffs, but the idea is that an object is constructed at the other end that has all the same data members as the object you had at this end. Perhaps with a flexible enough class definition, you could represent all or at least several of your messages with the same object. I am curious about your topology. You're sending events from the client (which presumably has a mouse and keyboard) to a server. But what does the server do with those? Does it have its own screen, or what? I'll try to explain. I am writing a fairly standard business/accounting application. (I am now adding Business Process Management to it, which is complicating matters, but that is another story.) Most of the gui stuff is basic forms processing - screens with static data, text fields for display and input of data, and buttons for signifying certain actions to be taken. My original attempt had both the gui and the business logic running on the client, with a connection to a database running on a server. It worked, but then I realised it was very insecure - it would be easy to hack the python code, bypass the business logic, and allow any update to the database. So my second attempt took all the business logic out of the client and put it onto the server. To execute a form, the server builds a form definition by creating objects to represent each of the widgets, creates a list of the components with sufficient information for the client to render them , then sends a json'd copy of the list to the client, which interprets it and displays the required form. The client informs the server of each event, and the server handles the event in much the same way as it did before when the business logic was on the client. For example, clicking a button triggers a response which could involve updating the database, displaying another window with additional data, etc, etc. Previously there would have been a method on the client designed to handle the response, and the method would be added to the button constructor so that it would be called when the button was clicked. Now the method is on the server, and is stored as an attribute of the button object on the server. When the user clicks the button, the message is passed up to the server (each widget has its own id, which is part of the message), the server is notified that the button was clicked, and it calls the associated method. There is a lot more to it than that, but hopefully that will give you an idea. If I ever get this to a workable state (it is taking far longer than I anticipated) I will release it as open source, and will then welcome as much feedback as possible. Frank OK, that makes good sense. And I withdraw any suggestion to use pickling, since that could be subject to hacking. It now appears that the messages are only incidentally GUI events. And that you would be well advised to make every possible event a separate message, so that if the server state and the client state get out of synch, you can readily check and reject such operations. For example, you'd have a message for pressing the SUBMIT button on a particular form, but you'd have different message types for other buttons on the same form, or for SUBMIT on other forms. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Object's nesting scope
On 27 авг, 19:19, Carl Banks wrote: > On Aug 27, 8:01 am, zaur wrote: > > > On 27 авг, 18:34, Carl Banks wrote: > > > The idea has been > > > discussed in various forms here quite a bit over the years. I doubt > > > there's any chance it'll be accepted into Python, because it goes > > > against one of the main design points of Python: that attributes > > > should always be accessed explicitly. > > > I don't in general consider this idea as a way for implicit access to > > object's attributes. > > That's what is it regardless of what you consider it. > > > Idea is about to use in some way object's dictionary as nested scope > > in a code block. > > Which is implicitly accessing the object's attributes. > > Carl Banks In my opinion idea of using object's dictionary as nested scope is more about structuring code blocks rather than just saving typing and implicit attribute access. -- http://mail.python.org/mailman/listinfo/python-list
Re: ubuntu dist-packages
On Thu, Aug 27, 2009 at 8:27 AM, Diez B. Roggisch wrote: > Paul Boddie wrote: > >> On 26 Aug, 17:48, Jorgen Grahn wrote: >>> >>> Well, if you are thinking about Debian Linux, it's not as much >>> "ripping out" as "splitting into a separate package with a non-obvious >>> name". Annoying at times, but hardly an atrocity. >> >> Indeed. Having seen two packages today which insisted on setuptools, >> neither really needing it, and with one actively trying to download >> stuff from the Internet (fifteen seconds warning - how generous!) when >> running setup.py, it seems to me that it isn't the distribution >> packagers who need to be re-thinking how they install Python software. >> >> Generally, distributions have to manage huge amounts of software and >> uphold reasonable policies without creating unnecessary maintenance. >> Sadly, until very recently (and I'm still not entirely sure if there's >> really been an attitude change) the Pythonic packaging brigade has >> refused to even consider the needs of one of the biggest groups of >> consumers of the upstream code. Consequently, distributions will >> always devise different ways of storing installed Python software, >> documentation and resources, mostly because the Pythonic tools have >> been deficient, particularly in the management of the latter >> categories. > > You mean it's the problem of the python packaging that it can't deal with > RPMs, debs, tgzs, OSX bundles, MSIs and > ? Of course it is - not because distutils should know about them but on the contrary because it should be possible to tweak the installation parameters to accomodate the various packaging solutions. Autotools, cmake, etc... do not need anything about rpm, debian, msi, and yet, they can be used to that purpose. cheers, David -- http://mail.python.org/mailman/listinfo/python-list
Re: ubuntu dist-packages
Robin Becker writes:
> Florian Diesch wrote:
> .
>>
>>>From /usr/lib/python2.6/site.py:
>>
>> ,
>> | For Debian and derivatives, this sys.path is augmented with directories
>> | for packages distributed within the distribution. Local addons go
>> | into /usr/local/lib/python/dist-packages, Debian addons
>> | install into /usr/{lib,share}/python/dist-packages.
>> | /usr/lib/python/site-packages is not used.
>> `
>
> the above is not present in my windows documentation (or indeed
> site.py) at all so it seems they just decided to change the
> name. Anyone trying to debug why their distutils or setuptools or
> whichever python packager is going wrong will have yet another detail
> to remember.
setuptools works fine for me in Ubuntu 9.04; eggs go to
/usr/local/lib/python2.6/dist-packages/ like they should according to site.py
> In addition, as any one who has done such trivial changes
> will already know, they forgot to do it globally eg my 0.4.1.0 version
> of the "Debian Python Policy" document explicitly mentions
> site-packages.
It's a change for the Python 2.6 package, see
and /usr/lib/python2.5/site.py
Python 2.6 is only in Debian experimental, I guess there is a new
version of the Debian Python Policy coming.
Florian
--
Re: Python on the Web
Thanks Graham. I actually ended up reading that blog post from a Google search last night before I saw your response. It was very informative. Bruno, I will take a look at those groups to expand my knowledge. When I gave that arbitrary percentage, I was basing it off of the information I had seen with regards to launching applications built with existing frameworks using lighttpd. I do realize I was missing a lot of information by looking up something that specific. I also understand that there are enough frameworks. That still won't change my mind. I do not want to write a web application, otherwise I would use an existing framework as suggested. I just wanted to experiment and see what kind of framework I could develop with some ideas I had in mind. The original post was mostly just because I was having a difficulty understanding some lower level concepts as a result of trying to get Python 3 on the web before figuring out that it wasn't quite ready for that. I just really like some of the new features of Python 3, and most importantly, unicode compliance is just that much straight forward in my opinion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding iadd for dictionary like objects
On 2009-08-27 01:49 AM, RunThePun wrote: Anybody have any more ideas? I think python should/could havev a syntax for overriding this behaviour, i mean, obviously the complexity of supporting all operators with the getitem syntax could introduce alot of clutter. But maybe there's an elegant solution out there... I would recommend just adding a method to MyDict that does exactly what you want. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
On 2009-08-27 07:41 AM, David House wrote: 2009/8/27 Terry Reedy: reply-all may send duplicate messages to the author. Not sure of this list. I'm fairly sure Mailman deals with that. Many of us read from comp.lang.python for gmane.comp.python.general. I do not appreciate getting reply emails to my inbox. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10
"James Harris" wrote in message news:[email protected]... On 22 Aug, 10:27, David <[email protected]> wrote: >They look good - which is important. The trouble (for me) is that I >want the notation for a new programming language and already use these >characters. I have underscore as an optional separator for groups of >digits - 123000 and 123_000 mean the same. The semicolon terminates a >statement. Based on your second idea, though, maybe a colon could be >used instead as in XPL uses "(2)1011" for base 4, "(3)03212" for octal, "(4)0741" for base 16. PL/I uses 8FXN for numeric hex and X suffix for a hex character constant. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pylint 0.18.1 / astng 0.19.1
Hi there, I'm pleased to announce a new bug fixes release of pylint and astng. To see what have been fixed and to download it (unless your using debian, ubuntu or easy_install of course :), check: http://www.logilab.org/project/pylint/0.18.1 http://www.logilab.org/project/logilab-astng/0.19.1 -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework:http://www.cubicweb.org -- http://mail.python.org/mailman/listinfo/python-list
(Simple?) Unicode Question
Hi All! I have a very simple (and probably stupid) question eluding me. When exactly is the char-set information needed? To make my question clear consider reading a file. While reading a file, all I get is basically an array of bytes. Now suppose a file has 10 bytes in it (all is data, no metadata, forget the BOM and stuff for a little while). I read it into an array of 10 bytes, replace, say, 2nd bytes and write all the bytes back to a new file. Do i need the character encoding mumbo jumbo anywhere in this? Further, does anything, except a printing device need to know the encoding of a piece of "text"? I mean, as long as we are not trying to get a symbolic representation of a "text" or get "i"th character of it, all we need to do is to carry the intended encoding as an auxiliary information to the data stored as byte array. Right? --shashank -- http://mail.python.org/mailman/listinfo/python-list
Re: About diagram and python
[email protected] wrote: Hello! I see on my Diagram Editor software this : File -> Export... -> (on Export option is : PyDia Code Generation ... .py) What python is in this file ? How help me with python code ? Thank you ! And when I start my car the radio is tuned to the wrong station. Could somebody tell me how to change the tubes on it? Or maybe I have a flat tire? When asking a question, give enough information that somebody has a chance of answering it. Otherwise you're wasting your time and ours. There are hundreds of "diagram editors" out there. Brand, version, maybe the URL to a website to download it. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: (Simple?) Unicode Question
Further, does anything, except a printing device need to know the encoding of a piece of "text"? I may be wrong, but I believe that's part of the idea between separation of string and bytes types in Python 3.x. I believe, if you are using Python 3.x, you don't need the character encoding mumbo jumbo at all ;-) If you're using Python 2.x, though, I believe if you simply set the file opening mode to binary then data you read() should still be treated as an array of bytes, although you may encounter issues trying to access the n'th character. Please do correct me if I'm wrong, anyone. On Thu, 27 Aug 2009 09:39:06 -0700, Shashank Singh wrote: Hi All! I have a very simple (and probably stupid) question eluding me. When exactly is the char-set information needed? To make my question clear consider reading a file. While reading a file, all I get is basically an array of bytes. Now suppose a file has 10 bytes in it (all is data, no metadata, forget the BOM and stuff for a little while). I read it into an array of 10 bytes, replace, say, 2nd bytes and write all the bytes back to a new file. Do i need the character encoding mumbo jumbo anywhere in this? Further, does anything, except a printing device need to know the encoding of a piece of "text"? I mean, as long as we are not trying to get a symbolic representation of a "text" or get "i"th character of it, all we need to do is to carry the intended encoding as an auxiliary information to the data stored as byte array. Right? --shashank -- Rami Chowdhury "Never attribute to malice that which can be attributed to stupidity" -- Hanlon's Razor 408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD) -- http://mail.python.org/mailman/listinfo/python-list
Re: (Simple?) Unicode Question
On Thu, 2009-08-27 at 22:09 +0530, Shashank Singh wrote: > Hi All! > > I have a very simple (and probably stupid) question eluding me. > When exactly is the char-set information needed? > > To make my question clear consider reading a file. > While reading a file, all I get is basically an array of bytes. > > Now suppose a file has 10 bytes in it (all is data, no metadata, > forget the BOM and stuff for a little while). I read it into an array > of 10 > bytes, replace, say, 2nd bytes and write all the bytes back to a new > file. > > Do i need the character encoding mumbo jumbo anywhere in this? > > Further, does anything, except a printing device need to know the > encoding of a piece of "text"? I mean, as long as we are not trying > to get a symbolic representation of a "text" or get "i"th character > of it, all we need to do is to carry the intended encoding as > an auxiliary information to the data stored as byte array. If you are just reading and writing bytes then you are just reading and writing bytes. Where you need to worry about unicode, etc. is when you start treating a series of bytes as TEXT (e.g. how many *characters* are in this byte array).* This is no different, IMO, than treating a byte stream vs a image file. You don't, need to worry about resolution, palette, bit-depth, etc. if you are only treating as a stream of bytes. The only difference between the two is that in Python "unicode" is a built-in type and "image" isn't ;) * Just make sure that if you are manipulating byte streams independent of it's textual representation that you open files, e.g., in binary mode. -a -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
On 2009-08-27, Robert Kern wrote: > On 2009-08-27 07:41 AM, David House wrote: >> 2009/8/27 Terry Reedy: >>> reply-all may send duplicate messages to the author. Not sure of this list. >> >> I'm fairly sure Mailman deals with that. > > Many of us read from comp.lang.python or gmane.comp.python.general. > I do not appreciate getting reply emails to my inbox. Same here. I haven't noticed it happening much for c.l.p, but on some other lists it seems to be a common (and annoying) practice. For those lists, I usually set up e-mail filters for those lists to route such replys to /dev/null. I haven't yet done so for c.l.p... -- Grant Edwards grante Yow! I just forgot my whole at philosophy of life!!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to [email protected]
Xavier Ho wrote: On Thu, Aug 27, 2009 at 7:04 PM, Dave Angel wrote: Thanks for those pointers. For example, I see a single message containing typically around 10 attachments. I do the reply-all to one of these attachments, and it handles the message body okay, the To/CC fields okay, What do you mean 10 attachments? O_o. I know some people like to attach a company logo in their signature. (The Aussie DLF list people do that heaps. Although some people post a hand-written sig in the attachment ... I'm not sure how smart that is, but I've seen it done.) Where are you getting these "attachments"? The message is a "digest" containing between 1 and 20 messages. The "index" is in the main message, and all the actual messages are encoded as attachments. I also see actual attachments, and sometimes signatures as attachments. But the ones I'm talking about have extension .eml. I haven't tried reply-all yet. May give that a try next time and see what pops up in the To: address. usually adds an extra RE: on the subject (so it becomes RE: RE: subject). Gmail doesn't do that. Yay! (Re: is dumb anyway, and you can't prepend Re: forever. Fwd: is reasonable.) If I have a direct message with a Re: at the beginning, Thunderbird does not add an extra one to my reply subject. Only when I'm doing it on one of these attachments. I didn't know ** marks bold. Does __ mark underline? Those are cool things I never hear about. Thanks! I don't know about any others other than *bold* text. And I don't know if it shows up in everyone's viewer that way, or just some. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Reference question
Thanks to everyone who responded. I will be going with some sort of a = MyClass(name = 'a') format. It's the Python way. For me, it was very hard to accept that EVERYTHING is an object reference. And that there are no object reference names, just string entries in dictionaries. But I think it all makes sense now. Thanks again, Josef On Aug 21, 1:07 am, josef wrote: > To begin, I'm new with python. I've read a few discussions about > object references and I think I understand them. > > To be clear, Python uses a "Pass By Object Reference" model. > x = 1 > x becomes the object reference, while an object is created with the > type 'int', value 1, and identifier (id(x)). Doing this with a class, > x = myclass(), does the same thing, but with more or less object > attributes. Every object has a type and an identifier (id()), > according to the Python Language Reference for 2.6.2 section 3.1. > > x in both cases is the object reference. I would like to use the > object to refer to the object reference. If I have a gross > misunderstanding, please correct me. > > The following is what I would like to do: > I have a list of class instances dk = [ a, b, c, d ], where a, b, c, d > is an object reference. Entering dk gives me the object: [MyClass0 > instance at 0x, MyClass1 instance at 0x0008, MyClass2 instance at > 0x0010 ... ] > > I need the object reference name (a,b,c,d) from dk to use as input for > a file. Where do I find the memory location of the object reference > and the object reference name memory location? I am unconcerned with > the fact that the memory location will change the next time I run a > python session. I will be using the object reference name for > processing right away. > > My main focus of this post is: "How do I find and use object reference > memory locations?" > > Thoughts? > Thanks, > > Josef -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Aug 26, 2009, at 1:11 PM, kj wrote: I think I understand the answers well enough. What I *really* don't understand is why this particular "feature" of Python (i.e. that functions defined within a class statement are forbidden from "seeing" other identifiers defined within the class statement) is generally considered to be perfectly OK. IMO it's a bizarre, inexplicable blindspot (which, among other things, gives rise to a certain worry about what other similar craziness lurks under Python's image of rationality). I have never seen even a half-hearted justification, from a language design point of view, for why this particular "feature" is worth having. Guido's design justifications: http://mail.python.org/pipermail/python-dev/2000-November/010598.html -- My personal justification: Python has used the same basic method of class creation since the very beginning: create a new local namespace, execute the class suite in that namespace, and then create a class, using the contents of the namespace as the class attributes. The important thing to note here is that there are really *two* namespaces--the local namespace that exists while the class suite is being executed (what I call the "suite namespace"), and the namespace of the class itself--and the first ceases to exist when the second is created. The two namespaces generally contain the same names at the point that the transfer occurs, but they don't have to; the metaclass (which constructs the class) is free to mess with the dictionary of attributes before creating the class. Suppose for a moment that the suite namespace *were* visible to nested scopes. The simplest and most consistent implementation would be to have a closure generated by a class statement be similar to that generated by a function--i.e., the closure would be over the suite namespace. This hardly seems desirable, though, because the suite namespace and the class namespace would get out of sync when different objects were assigned to the class namespace: class C: x = 1 def foo(self): print x print self.x >>> o = C() >>> o.foo() 1 1 >>> o.x = 2 >>> o.foo() 1 2 Surely such an implementation would be considered an even larger Python wart then not having the suite namespace visible to nested scopes at all. But it's better than the alternative of trying to unify the class suite namespace and the class namespace, which would be a nightmare of special cases (adding/deleting class attributes? descriptors? __getattr__?) and require an implementation completely separate from that of normal nested scopes. -Miles P.S. Just for fun: import types def make_class(*bases): """Decorator to allow you to (ab)use a function as a class definition. The function must take no arguments and end with 'return locals()'; bases are (optionally) specified as arguments to make_class; metaclasses other than 'type' are not supported. >>> @make_class ... def C(): ... greeting = 'Hello' ... target = 'world' ... def greet(self): ... print '%s, %s' % (self.greeting, target) ... return locals() ... >>> C().greet() Hello, world """ def decorator(func): return type(func.func_name, bases, func()) if len(bases) == 1 and isinstance(bases[0], types.FunctionType): func = bases[0] bases = (object,) return decorator(func) if not bases: bases = (object,) return decorator -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
Steven D'Aprano wrote: A mistake is still a mistake even if it shared with others. Treating its with a lead zero as octal was a design error when it was first thought up [snippage] I have to disagree with you on this one. The computing world was vastly different when that design decision was made. Space was at a premium, programmers were not touch-typists, every character had to count, and why in the world would somebody who had to use papertape or punch cards add a lead zero without a *real* good reason? I submit that that real good reason was to specify an octal literal, and not a decimal literal. Now many many years have passed, much has changed, and a leading zero (like so much else) no longer makes the sense in once did -- especially in a very wide-spread and general purpose language like Python. That does not mean it was not a very good decision at the time. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
Ethan Furman wrote: Steven D'Aprano wrote: A mistake is still a mistake even if it shared with others. Treating its with a lead zero as octal was a design error when it was first thought up [snippage] I have to disagree with you on this one. The computing world was vastly different when that design decision was made. Space was at a premium, programmers were not touch-typists, every character had to count, and why in the world would somebody who had to use papertape or punch cards add a lead zero without a *real* good reason? I submit that that real good reason was to specify an octal literal, and not a decimal literal. Now many many years have passed, much has changed, and a leading zero (like so much else) no longer makes the sense in once did -- especially in a very wide-spread and general purpose language like Python. That does not mean it was not a very good decision at the time. I think that it although it might have been reasonable when C was invented, it wasn't a good idea when Python was invented. -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On Aug 26, 10:27 pm, Steven D'Aprano wrote: > On Wed, 26 Aug 2009 18:53:04 -0700, Erik Max Francis wrote: > >> In any case, unary is the standard term for what I'm discussing: > > >>http://en.wikipedia.org/wiki/Unary_numeral_system > This really isn't anywhere near as controversial as you guys are making > it. Words sometimes have meanings different from what you expect from > reasoning by analogy. Get over it. Fine. I'm over it. Point is, I HAVE encountered plenty of people who DON'T properly understand it, Marilyn Vos Savant, for example. You can't blame me for thinking you don't understand it either when unary is brought up in a discussion of how to interpret insignificant leading 0's. > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
regexp help
If I were using the code: (?P[0-9]+) to get an integer between 0 and 9, how would I allow it to register negative integers as well? -- http://mail.python.org/mailman/listinfo/python-list
Re: regexp help
You can use r"[+-]?\d+" to get positive and negative integers. It returns true to these strings: "+123", "-123", "123" On Thu, Aug 27, 2009 at 3:15 PM, Bakes wrote: > If I were using the code: > > (?P[0-9]+) > > to get an integer between 0 and 9, how would I allow it to register > negative integers as well? > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on Crays
On Aug 25, 11:34 pm, Carrie Farberow wrote: > Ok, here are links to word documents outlining the commands I executed as > well as the make.log file and the make_install.log file > [links snipped] So from the output of make, it looks as though none of the modules specified in the Modules/Setup file is being built at all on your system. So not just unicodedata, but the math, cmath, array, itertools modules and more are missing from your build. You can check this by running Python: after the make step finishes, you should have a working Python executable called 'python' in the current directory; if you start it up and then type 'import math' at the '>>>' prompt, I'm guessing you'll get an error message that looks something like: ImportError: No module named math I don't have much idea why those modules aren't being built; I tried imitating the relevant parts of your instructions (to the degree that they make sense on my non-Cray system) without any problems. Anyway, I agree that issue1594809 doesn't look so relevant; the only common factor is that in both cases Python is failing to find the unicodedata module; but in that issue the unicodedata module is present but doesn't get found because the paths are messed up, while in your case the unicodedata module isn't being built at all. Suggestions: (1) double check that you've uncommented the appropriate lines in the Modules/Setup file. E.g., after the configure step, there's a line in Modules/Setup that looks like: #unicodedata unicodedata.c# static Unicode character database that leading '#' should be removed so that it looks like: unicodedata unicodedata.c# static Unicode character database and similarly for the other modules in that section. Make sure that you're editing the Modules/Setup file *after* the configure step and *before* the make step. (2) Find a local Unix/Python guru and ask him/her to help out. These sorts of problems are generally much easier to figure out when you've got direct access to the machine. Sorry I can't be more help than this. -- Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Reference question
josef wrote: Thanks to everyone who responded. I will be going with some sort of a = MyClass(name = 'a') format. It's the Python way. For me, it was very hard to accept that EVERYTHING is an object reference. And that there are no object reference names, just string entries in dictionaries. But I think it all makes sense now. Thanks again, Josef My apologies if I missed it, but what *exactly* are you planning on doing with your 'name' attribute? From the posts I've seen so far, I think you are only setting yourself up for failure. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Question on the "csv" library
I am trying to read a csv file generated by excel.
Although I succeed in reading the file, the format that I get is not
suitable for me.
I've done:
>>> import csv
>>> spamReader = csv.reader(open('C:\\abc.csv', 'r'))
>>> print spamReader
<_csv.reader object at 0x01022E70>
>>> for row in spamReader:
print row
['codigo;nombre;cantidad']
['a;qwe;1']
['b;asd;2']
['c;zxc;3']
My questions are:
1- Why using "print spamReader" I cannot see the data?
I expected to see a list of lists, a kind of a matrix, but I get
nothing
2- Why are the rows in a single string?
I expected a list of fields that, when text, would be delimited by
"
To tell the truth, the file generated by excel does not contain the
strings delimited by ". Isn't it weird?
3- Is there anything I can do to have my data in a list of lists
structure? would another kind of data suit better my needs?
Thank you for your help
Vicente Soler
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python on Crays
Who the one from wisconsin and did you try the python group in madison maybe they can help. Well i from madison are and i just a newbie with python.What OS you useing? --- On Thu, 8/27/09, Mark Dickinson wrote: > From: Mark Dickinson > Subject: Re: Python on Crays > To: [email protected] > Date: Thursday, August 27, 2009, 1:48 PM > On Aug 25, 11:34 pm, Carrie Farberow > > wrote: > > Ok, here are links to word documents outlining the > commands I executed as well as the make.log file and the > make_install.log file > > [links snipped] > > So from the output of make, it looks as though none of the > modules specified in the Modules/Setup file is being built > at all on your system. So not just unicodedata, but > the > math, cmath, array, itertools modules and more are > missing from your build. > > You can check this by running Python: after the make > step > finishes, you should have a working Python executable > called > 'python' in the current directory; if you start it up > and > then type 'import math' at the '>>>' prompt, I'm > guessing > you'll get an error message that looks something like: > > ImportError: No module named math > > I don't have much idea why those modules aren't being > built; > I tried imitating the relevant parts of your instructions > (to the degree that they make sense on my non-Cray system) > without any problems. > > Anyway, I agree that issue1594809 doesn't look so > relevant; > the only common factor is that in both cases Python is > failing to find the unicodedata module; but in that > issue > the unicodedata module is present but doesn't get found > because the paths are messed up, while in your case the > unicodedata module isn't being built at all. > > Suggestions: > > (1) double check that you've uncommented the appropriate > lines > in the Modules/Setup file. E.g., after the configure > step, there's > a line in Modules/Setup that looks like: > > #unicodedata unicodedata.c # static Unicode > character database > > that leading '#' should be removed so that it looks like: > > unicodedata unicodedata.c # static Unicode > character database > > and similarly for the other modules in that section. > Make sure that you're editing the Modules/Setup file > *after* the configure step and *before* the make step. > > (2) Find a local Unix/Python guru and ask him/her to > help out. These sorts of problems are generally much > easier to figure out when you've got direct access to > the machine. > > Sorry I can't be more help than this. > > -- > Mark > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: How does the file.seek() work ?
On Aug 26, 7:28 pm, gert wrote:
> On Aug 26, 12:46 am, Graham Dumpleton
> wrote:
>
>
>
> > On Aug 25, 5:37 am, Tim Chase wrote:
>
> > > > I want the file pointer set to 100 and overwrite everything from there
> > > [snip]
> > > > def application(environ, response):
> > > > query=os.path.join(os.path.dirname(__file__),'teemp')
> > > > range=environ.get('HTTP_RANGE','bytes=0-').replace
> > > > ('bytes=','').split(',')
> > > > offset=[]
> > > > for r in range: offset.append(r.split('-'))
> > > > with open(query,'w+') as f:
> > > > f.seek(int(offset[0][0]))
> > > > while True:
> > > > chunk=environ['wsgi.input'].read(8192).decode('latin1')
> > > > if not chunk: break
> > > > f.write(chunk)
> > > > f=open(query)
> > > > l=str(os.fstat(f.fileno()).st_size)
> > > > response('200 OK', [('Content-Type', 'text/plain'), ('Content-
> > > > Length', str(len(l)))])
> > > > return [l]
>
> > > A couple items of note:
>
> > > - you don't open the file in binary mode -- seek is more reliable
> > > in binary mode :)
>
> > If my memory is right, if file is opened in binary mode, also wouldn't
> > need to be decoding the WSGI input stream as latin-1 to get a string.
> > Instead can just deal with bytes and write bytes to file.
>
> > Graham
>
> > > - if you want to lop off the rest of the file, use f.truncate()
>
> > > An example:
>
> > > # create the initial file
> > > >>> f = file('zzz.zzz', 'wb+')
> > > >>> f.write('abcdefghijklmnop')
> > > >>> f.close()
>
> > > >>> f = file('zzz.zzz', 'ab+')
> > > >>> f.read() # show the existing content
> > > 'abcdefghijklmnop'
> > > >>> f.seek(5) # seek to the desired offset
> > > >>> f.truncate() # throw away everything after here
> > > >>> f.write('zyx') # write the new data at pos=5
> > > >>> f.close()
>
> > > # demonstrate that it worked
> > > >>> f = file('zzz.zzz', 'rb')
> > > >>> f.read()
> > > 'abcdezyx'
> > > >>> f.close()
>
> > > > also why must I open the file a second time to know how big it is ?
>
> > > Likely the output has been buffered. You can try using
>
> > > f.flush() # write all the data to the disk first
> > > size = os.fstat(f.fileno()).st_size
>
> > > which seems to do the trick for me.
> > > -tkc
>
> Works thanks
>
> curl -C 10 -T upload2.wsgihttp://192.168.2.17/appwsgi/wsgi/upload2.wsgi
> --header "Transfer-Encoding: chunked" -v
>
> import os
>
> def application(environ, response):
> #query=environ.get['QUERY_STRING']
> #print (query, file=environ['wsgi.errors'])
> query=os.path.join(os.path.dirname(__file__),'teemp')
> range=environ.get('HTTP_CONTENT_RANGE','bytes 0-').replace('bytes
> ','').split('/')[0].split(',')
> offset=[]
> for r in range: offset.append(r.split('-'))
> with open(query,'rb+') as f:
> f.seek(int(offset[0][0]))
> if environ['REQUEST_METHOD']=='PUT':
> f.truncate()
> while True:
> chunk=environ['wsgi.input'].read(8192)
> if not chunk: break
> f.write(chunk)
> f.flush()
> l=str(os.fstat(f.fileno()).st_size)
> response('200 OK', [('Content-Type', 'text/plain'), ('Content-
> Length', str(len(l)))])
> return [l]
Update it works on mod_wsgi but not on wsgiref.simple_server
C:\Users\gert\Desktop\hg\appwsgi\wsgi>curl -T upload2.wsgi
http://localhost/appwsgi/wsgi/upload2.wsg
i -v
* About to connect() to localhost port 80 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 80 (#0)
> PUT /appwsgi/wsgi/upload2.wsgi HTTP/1.1
> User-Agent: curl/7.19.4 (amd64-pc-win32) libcurl/7.19.4 OpenSSL/0.9.8j
> zlib/1.2.3
> Host: localhost
> Accept: */*
> Content-Length: 869
> Expect: 100-continue
>
* Done waiting for 100-continue
I not getting 100-continues ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
James Harris wrote: On 27 Aug, 18:31, Ethan Furman wrote: Steven D'Aprano wrote: A mistake is still a mistake even if it shared with others. Treating its with a lead zero as octal was a design error when it was first thought up [snippage] I have to disagree with you on this one. The computing world was vastly different when that design decision was made. Space was at a premium, programmers were not touch-typists, every character had to count, and why in the world would somebody who had to use papertape or punch cards add a lead zero without a *real* good reason? I submit that that real good reason was to specify an octal literal, and not a decimal literal. Nice idea. Characters were expensive but not that expensive - even then. One extra character to make the octal prefix 0t or 0q or something could have been used. Check out the History heading at http://sundry.wikispaces.com/octal-zero-prefix Note how B migrated away from both BCPL's octal and its hex notation. # and #x in BCPL became 0 and 0x in B James Nice link. I suspect that as much as anything is was abbreviate as much as possible. In unix we have copy as cp, list as ls move as mv, etc, etc. Different mind-set also when designing for yourself or a small group, versus thousands and thousands. I am in agreement that Python should not have a leading 0 for octal, as there are big inconsistencies with how it's treated. Visually, I would have preferred a prefix of 0c, but I understand it should be consistent with the string specifier of o. Oh well, win some, lose some. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Question on the "csv" library
On Thu, Aug 27, 2009 at 3:06 PM, vsoler wrote:
>
> I am trying to read a csv file generated by excel.
>
> Although I succeed in reading the file, the format that I get is not
> suitable for me.
>
> I've done:
>
> >>> import csv
> >>> spamReader = csv.reader(open('C:\\abc.csv', 'r'))
>
> >>> print spamReader
> <_csv.reader object at 0x01022E70>
>
> >>> for row in spamReader:
> print row
>
>
> ['codigo;nombre;cantidad']
> ['a;qwe;1']
> ['b;asd;2']
> ['c;zxc;3']
>
> My questions are:
>
> 1- Why using "print spamReader" I cannot see the data?
> I expected to see a list of lists, a kind of a matrix, but I get
> nothing
It's because csv.reader does the same thing open does. It returns an
iterable, not a list. The file is opened but not processed until you
iterate through it. You cannot see the data when you do print
spamReader because of this and because the csv reader object does
define a __str__ method.
>
> 2- Why are the rows in a single string?
> I expected a list of fields that, when text, would be delimited by
> "
> To tell the truth, the file generated by excel does not contain the
> strings delimited by ". Isn't it weird?
CSV stands for comma separated variables. It actually has nothing to
do with the quotes- they're just used in case an element has a comma
in it, so the reader knows it's a string literal and not a separate
column. Your comma separated variable worksheet seems to be semicolon
separated. That's why the reader isn't splitting it.
>
> 3- Is there anything I can do to have my data in a list of lists
> structure? would another kind of data suit better my needs?
>
just do a list comprehension
sheet = [row for row in spamReader]
> Thank you for your help
>
> Vicente Soler
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
> Mensanator (M) wrote: >M> On Aug 26, 4:59 pm, Piet van Oostrum wrote: >>> > Mensanator (M) wrote: >>> >M> That's my point. Since the common usage of "binary" is for >>> >M> Standard Positional Number System of Radix 2, it follows >>> >M> that "unary" is the common usage for Standard Positional >>> >M> Number System of Radix 1. That's VERY confusing since such >>> >M> a system is undefined. Remember, common usage does not >>> >M> necessarily properly define things. Saying simply "unary" >>> >M> sounds like you're extending common usage beyond its proper >>> >M> boundaries. >>> >>> But the customary meaning of `unary' is the tally system, as a radix >>> system wouldn't make sense. I don't know when this term came into use >>> but I have known it for a long time. >M> Ok, I'll accept that and in the same breath say such common usage >M> is stupid. I, for one, have never heard such usage and would never >M> use "unary" in the same breath as "decimal, octal, binary" even if >M> I had. As I see it, unary just means that there is one symbol. Binary just means that there are two symbols, etc. With unary, the only sensible numerical interpretation is to count the number of occurrences of that symbol, or if you also want to have the number 0, the number of occurrences - 1. With binary and higher you can come up with more numerical interpretations but the most efficient one is the radix interpretation (for different values of `efficient'). I doubt that there are many other interpretations that you can call sensible. Therefore we immediately think of a radix system when we talk about binary, octal, decimal etc. But the word `binary' itself doesn't imply that. -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On 27 Aug, 18:31, Ethan Furman wrote: > Steven D'Aprano wrote: > > A mistake is still a mistake even if it shared with others. > > > Treating its with a lead zero as octal was a design error when it was > > first thought up > > [snippage] > > I have to disagree with you on this one. The computing world was vastly > different when that design decision was made. Space was at a premium, > programmers were not touch-typists, every character had to count, and > why in the world would somebody who had to use papertape or punch cards > add a lead zero without a *real* good reason? I submit that that real > good reason was to specify an octal literal, and not a decimal literal. Nice idea. Characters were expensive but not that expensive - even then. One extra character to make the octal prefix 0t or 0q or something could have been used. Check out the History heading at http://sundry.wikispaces.com/octal-zero-prefix Note how B migrated away from both BCPL's octal and its hex notation. # and #x in BCPL became 0 and 0x in B James -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
MRAB wrote: Ethan Furman wrote: Steven D'Aprano wrote: A mistake is still a mistake even if it shared with others. Treating its with a lead zero as octal was a design error when it was first thought up [snippage] I have to disagree with you on this one. The computing world was vastly different when that design decision was made. Space was at a premium, programmers were not touch-typists, every character had to count, and why in the world would somebody who had to use papertape or punch cards add a lead zero without a *real* good reason? I submit that that real good reason was to specify an octal literal, and not a decimal literal. Now many many years have passed, much has changed, and a leading zero (like so much else) no longer makes the sense in once did -- especially in a very wide-spread and general purpose language like Python. That does not mean it was not a very good decision at the time. I think that it although it might have been reasonable when C was invented, it wasn't a good idea when Python was invented. Very good point. I was thinking Steven was talking about the earliest case, as opposed to the earliest Python case. My apologies if I misunderstood. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str in windows xp, while making tarfile
> Ryniek90 (R) wrote: >R> Hahah right. My fault. Must remember to read documentation so many times >R> until I find the solution. Thanks, now works fine. :-) And, by the way, how come the traceback refers to File "backuper.py", line 197, in while the posted code has only 188 lines? -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
Re: Question on the "csv" library
On Thu, 27 Aug 2009 21:36:28 +0200 Andreas Waldenburger wrote: > [snip] > > Might I humbly suggest > > >>> sheet = list(spamReader) # ? > Oh, and while I'm humbly suggesting: spam_reader instead of spamReader or SpamReader or SpamrEadeR or suchlike. Caps are "reserved" for classes. Not a necessity, of course. But it's the dialect around these parts. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on Crays
I am from Wisconsin -- is there a python group here? Do you have any contact info.? The compute node operating system is Compute Node Linux (CNL). Carrie - Original Message - From: Craig Date: Thursday, August 27, 2009 2:15 pm Subject: Re: Python on Crays To: [email protected], Mark Dickinson > Who the one from wisconsin and did you try the python group in madison > maybe they can help. > > Well i from madison are and i just a newbie with python.What OS you useing? > > --- On Thu, 8/27/09, Mark Dickinson wrote: > > > From: Mark Dickinson > > Subject: Re: Python on Crays > > To: [email protected] > > Date: Thursday, August 27, 2009, 1:48 PM > > On Aug 25, 11:34 pm, Carrie Farberow > > > > wrote: > > > Ok, here are links to word documents outlining the > > commands I executed as well as the make.log file and the > > make_install.log file > > > [links snipped] > > > > So from the output of make, it looks as though none of the > > modules specified in the Modules/Setup file is being built > > at all on your system. So not just unicodedata, but > > the > > math, cmath, array, itertools modules and more are > > missing from your build. > > > > You can check this by running Python: after the make > > step > > finishes, you should have a working Python executable > > called > > 'python' in the current directory; if you start it up > > and > > then type 'import math' at the '>>>' prompt, I'm > > guessing > > you'll get an error message that looks something like: > > > > ImportError: No module named math > > > > I don't have much idea why those modules aren't being > > built; > > I tried imitating the relevant parts of your instructions > > (to the degree that they make sense on my non-Cray system) > > without any problems. > > > > Anyway, I agree that issue1594809 doesn't look so > > relevant; > > the only common factor is that in both cases Python is > > failing to find the unicodedata module; but in that > > issue > > the unicodedata module is present but doesn't get found > > because the paths are messed up, while in your case the > > unicodedata module isn't being built at all. > > > > Suggestions: > > > > (1) double check that you've uncommented the appropriate > > lines > > in the Modules/Setup file. E.g., after the configure > > step, there's > > a line in Modules/Setup that looks like: > > > > #unicodedata unicodedata.c # static Unicode > > character database > > > > that leading '#' should be removed so that it looks like: > > > > unicodedata unicodedata.c # static Unicode > > character database > > > > and similarly for the other modules in that section. > > Make sure that you're editing the Modules/Setup file > > *after* the configure step and *before* the make step. > > > > (2) Find a local Unix/Python guru and ask him/her to > > help out. These sorts of problems are generally much > > easier to figure out when you've got direct access to > > the machine. > > > > Sorry I can't be more help than this. > > > > -- > > Mark > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
> kj (k) wrote: >k> No, the fact() function here represents an internal "helper" >k> function. It is meant to be called only once to help initialize >k> a class variable that would be inconvenient to initialize otherwise; >k> this helper function is not meant to be called from outside the >k> class statement. Granted, in the example I gave, the "helper" >k> function (factorial) is a bit silly, but that was just intended as >k> a simple and familiar example of a recursive function. The actual >k> function that motivated this post would be considerably more >k> difficult to explain and would have obscured the point of the post. Classes don't have helper functions; they have methods. Instance methods, static methods or class methods. Your's isn't either of these. Methods are to be called like `something.method(...)'. -- Piet van Oostrum URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: [email protected] -- http://mail.python.org/mailman/listinfo/python-list
