Re: Python GUI?
On 13 September 2013 15:39, John Gordon gor...@panix.com wrote: In 76784bad-cd6d-48f9-b358-54afb2784...@googlegroups.com eamonn...@gmail.com writes: they're making programming easier... by not coding as much. Oh well, guess coding is dead :( Pressing keys on a keyboard was never the hard part of coding. Nor the fun part. Joe -- https://mail.python.org/mailman/listinfo/python-list
Re: Python GUI?
On 13 September 2013 16:37, eamonn...@gmail.com wrote: I disagree with you. It's not hard, and I apologise if its ever sounded that way, but it is the fun part for me. I love spending hours(days even) debugging. Well, thanks all for depressing me. Time to give up programming and find something else to do with my life. -- https://mail.python.org/mailman/listinfo/python-list lol! You made my day. :-D Well, you can always ignore any and all graphical design tools if you're working alone. And write all those Xs and Ys and widths and heights all day long. None of the mentioned graphical toolkits forces you to use them. And if you like debugging, GUI is not the main dish! Try networking and concurrent programming, loads and loads of fun! Of course, that's lots of other unnecessary time consuming stuff you can do. You just have to use your imagination. Joe -- https://mail.python.org/mailman/listinfo/python-list
Re: better and user friendly IDE recommended?
On 12 September 2013 13:00, Veritatem Ignotam veritatem.igno...@gmail.com wrote: Is this thread going to evolve into your classic vim vs. emacs, sweet! Who doesn't love those? ;-) On 09/12/2013 11:47 AM, Paul Rudin wrote: Joshua Landau jos...@landau.ws writes: If the time learning a set of tools is enough to make the choice between tools, I suggest avoiding, say, Vim. That's a big if. If you expect to spend a lot of time editing text, code, etc. over the next few years then it's definitely learning at least one of vim or emacs to a reasonable degree of competency. I kinda disagree. Though I use and love emacs as my main editor, simple things you take for granted in modern editors are simply not there, and you end up spending some precious time finding out how to have it (like a right-margin marker). Of course that's not a real issue, since in the end you'll have everything and much more after configuring and saving your .emacs in the cloud so everything is always to your liking. But then comes another problem: we don't live in a bubble. If you'll ever have to use another programmer's box, you're screwed (That's why I avoid getting used to non-standard packages). Not to mention the mental switch. Not everything I need to use has emacs-binding (I guess the same is true for vim-binding) and, most of the time, the binding sucks anyway. But the point I really disagree is that typing/editing speed impacts so much programmer's productivity. In my experience I spend a lot more time as a programmer (big emphasis on lot) reading, thinking and designing then writing code. So I find a good navigation tool more important. My solution/suggestion for python: emacs (in cua-mode for me) with Jedi. Joe -- https://mail.python.org/mailman/listinfo/python-list
Re: user interfaces python3.x
On 2 September 2013 14:00, Paul Rice lfcpaulr...@gmail.com wrote: I know that most of my time will be writing . I dont think i specified very well what im asking. What i mean by proper interface is a interface like for an app or something, let me give u an example; Say i have made a phonebook just for this example and i want to use it like a normal phonebook in your phone instead of in writing. So basically making it like an app or something ? Does that make sense ? Lol He's just messing with you. What you want is to write GUI (Graphical User Interface) Application. The examples Steven cited like GTK and Qt are libraries that provides it. The word Interface means a lot of things in programming. -- Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: user interfaces python3.x
On 2 September 2013 14:30, Joel Goldstick joel.goldst...@gmail.com wrote: On Mon, Sep 2, 2013 at 1:16 PM, Joe Junior joe.fbs.jun...@gmail.com wrote: On 2 September 2013 14:00, Paul Rice lfcpaulr...@gmail.com wrote: I know that most of my time will be writing . I dont think i specified very well what im asking. What i mean by proper interface is a interface like for an app or something, let me give u an example; Say i have made a phonebook just for this example and i want to use it like a normal phonebook in your phone instead of in writing. So basically making it like an app or something ? Does that make sense ? Lol He's just messing with you. What you want is to write GUI (Graphical User Interface) Application. The examples Steven cited like GTK and Qt are libraries that provides it. The word Interface means a lot of things in programming. Except that those libraries don't work in Android phone environments. I've never looked into writing code for a phone, but I would suppose that a prerequisite for writing smart phone apps is to understand more in general how to write a software application. Guessing from the way the OP poses his question, he has a lot more to learn than a specific GUI library. So, maybe the answers were a little facetious, but the question could be taken as either completely naive, or as completely pompous. To answer the second interpretation is maybe more fun! I'm always for some fun, I just thought I should tell the OP what was going on. :-) And Qt can work on Android, with some effort. But you're absolutely right, mobile development can be quite harder than desktop, and the OP has some studying to do. I'd recommend he first tried some desktop development, a little googling on tkinter or PyQt can do him good, since he wants to learn about GUI development, even though it might not directly translate to mobile developtment. -- Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface and duck typing woes
Well, the main reason for me asking this question here was because of the Java/C#/Whatever developer in me craving for an Interface for the container's items, and I noticed that I'm not alone in this. But I was actually expecting the We're all consenting adults, here, I guess I just needed the confirmation :-) Another reason for this question is that I read some people saying they wouldn't use python for large projects, and they always point at the lack of Interfaces as a concern. I actually disagree, but I can see their point. What do you think? @Nobody Of course I don't want to check isistance(), I like duck typing, but should I check if hasattr() and callable() before adding to the container? That won't tell you if the object has a quack() method but with incompatible semantics (e.g. wrong number or types of arguments). Yeah, didn't think about that, it's kinda swimming upstream! Definitely it is more hassle than it is worth. @ChrisA Do you believe that you can write code to catch every bug you might make? If so, you are naive and probably haven't spent much time programming yet :) And if not, then you must acknowledge that bugs WILL happen; therefore you will need to cope with them after the event. So rather than trying to prevent them all, just improve your means of coping, and you'll accomplish the same end with much less trouble. Oh, no! I'm not that presumptuous (or naive)! But what do you mean by improve means of coping? Do you know any article on the subject you could point me? @Steven Of course I don't want to check isistance(), I like duck typing, but should I check if hasattr() and callable() before adding to the container? What is the pythonic way to deal with it? Am I worrying too much ;-)? Yes :-) Well, thanks! :-) And thanks for the article. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interface and duck typing woes
On 29 August 2013 10:07, Chris Angelico ros...@gmail.com wrote: Hmm. l don't know of any good articles off-hand. But what I'm talking about is simply developing the skill of reading exceptions, plus a few simple things like knowing where it's appropriate to catch-and-log; sometimes, what that means is actually writing some code to (for example) email you whenever there's an exception, but more likely it means writing no code at all, and just looking at STDERR of your live usage. Works really well for 95% of Python scripts. The most important thing to consider is: What happens if my code doesn't run all the way through? Is it safe for this to run part way, then bomb with an exception? For many scripts, it's pretty easy: fix the problem and rerun the script, and it'll completely rewrite its output file. For others, this is a good reason for putting all your real data into a transactional database - you begin a transaction at the top, don't commit till the end, and if an exception kills your script, your transaction will be rolled back. I have a system for patching our database based on a script (written in Pike, not Python, but the same applies); if I have any sort of critical failure in the patch script, it'll bomb out as soon as I test it - but since I use PostgreSQL, all that DDL (eg ALTER TABLE) is covered by transactional integrity (which it isn't with MySQL - another reason to be wary of MySQL), so my patch will be backed out, and I can fix it and start over. I don't need to have a Look Before You Leap approach to database changes - I can simply do stuff, and if it crashes, all's well. (That same script also has a system for catching errors at a mid-level point that means that the process doesn't terminate when there's an error; it supports full code reload, so once I fix the patch, I send the process a SIGHUP and it fetches from disk again.) *That* is error handling the safe way. Oh, I get it! Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Interface and duck typing woes
While designing a simple library, I found myself asking a philosophical question: to check or not to check the parameter's interface? I think that, considering it is Python, the usual answer would be no, but here is the situation that got me thinking: class Flock: def __init__(self): self.ducks= [] def do_stuff(self): for duck in self.ducks: duck.quack() class Duck: def quack(self): #quack-quack pass f = Flock() d = Duck() f.ducks.append(d) f.do_stuff() Ok, no big deal there, the problem is if the user forgets to implement the quack() method. The stack trace would complain that duck.quack() is wrong, but that can happen hundreds of lines after the user actually added the object to the Flock, and it can be hard to find out what is happening and which object is wrong. Of course I don't want to check isistance(), I like duck typing, but should I check if hasattr() and callable() before adding to the container? What is the pythonic way to deal with it? Am I worrying too much ;-)? Thanks, Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: Class hierarchy problem
On Tue, Aug 6, 2013 at 12:36 PM, BrJohan brjo...@gmail.com wrote: On 06/08/2013 16:02, Chris Angelico wrote: My classhierarchy is like a multilevel tree where each non-leaf node (class) is given knowledge about its nearest subclasses and their 'capacities'. So, my idea is to let the 'upper' class recursively choose which of its nearest subclasses is the 'correct' one, until approaching a 'leaf' class from which the instance should be created. And, given my knowledge that a solution along the lines of this idea has been designed and was working, I'm still hopeful ... (or I'll have to investigate all those old backup-DVDs) [ responding on-list - I hope it was mere oversight that had this come privately to me alone ] This is code smell; this recursive search for the right class seems likely to be wrong. Can you have the classes perhaps register themselves in some way? On what basis is a superclass to determine that one of its subclasses should handle this request? ChrisA Consider a botanical classification system (somewhat analogous to my 'problem' as it effectively is related to classification of entities): A Domain should know about its Kingdoms, a Kingdom should know about its Phylums, ... a Genus should know about its Species. Of course it is possible to implement such a decision tree as a 'factory'. However, I would rather prefer to encapsulate those decisions at the class level where they 'belong'. BrJohan -- I think it's a has a vs a is a problem. A Domain has a Kingdom, a Kingdom is not a Domain, so it shouldn't actually inherit Domain. In this case you should use composition instead of inheritance. When you say that a A Domain should know about it's Kingdons note that you're talking about a specific Domain and it's specific Kingdons, which means, a Domain instance and various Kingdom instances. JoeS -- http://mail.python.org/mailman/listinfo/python-list
