Re: Python code in presentations
> Right now the method I'm using is write the code in notepad++, use a > plugin (NppExport) to copy paste code into powerpoint. After using it > a little bit, I'm really not satisfied with this method, it's > expensive and all this copy paste stuff is driving me crazy. Not to > mention that the syntax highlight from notepads renders like crap in > powerpoint. > > I wonder if some people in this list who have successfully presented > python code have some tips about doing the proper way. Ned's > presentations for pycons are to me one example of successful code > presentation: > - the layout is simple > - the code and code output are clearly identified > - a line of code can be highlighted while presenting LyX and Beamer. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: very lightweight gui for win32 + python 3.4
> wxPython and Qt are well known but they are not exactly lightweight. wxPython not lightweight? It's just a wrapper of win32. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> >> > Because on such operating systems, each and every application is > >> > an entirely self-contained package that doesn't need any > >> > "packages" or "installers" to use it. > > > >> For people who have never used such a system it's probably > >> difficult to see the advantages. > > > > That's the whole point. > > > > The problem is that the ones who "decide" (well, they pretend to, > > but actually can't, because they don't know the alternatives) are > > always people who are "not even clueless". > > Ha! I love it. I presume that's an allusion to that-other-Wolfgang's > apocryphal "not even wrong" comment. :) Exactly. And it's also an allusion to that statement that "knowledge means to know what you don't know". Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> >> By the way, you keep replying to people, and quoting them, but > >> deleting their name. Please leave the attribution in place, so we > >> know who you are replying to. > > > > That's what the "References:"-Header is there for. > > The References header is for the benefit of news and mail clients, > not human readers. Any half-decent news client will happily display a thread tree for you. Based on that References:-Header. > It is rude to deliberately refuse to give attributes: > So please stop being rude, and follow the convention of both email and > usenet (as well as broader society) to give attribution to those you > quote. I've been using mail and news for over 20 years now, you definitely don't need to teach me anything. End of subthread. Good Bye, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> >> > Thankfully, all actually user-friendly operating systems (MacOS, > >> > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the > >> > bottomless cesspit of "package management" and/or "installers". > >> > > >> > Because on such operating systems, each and every application is > >> > an entirely self-contained package that doesn't need any > >> > "packages" or "installers" to use it. > >> > >> You mean everyone has to reinvent the proverbial wheel AND worry > >> about dependency collisions? Yeah, that's a heavenly thought. > > > > You should get a clue in stead of just fantasizing up assumptions > > based on ignorance. > > I've worked with a number of operating systems, a number of dependency > management systems, and a number of absences of such systems. I stand > by my earlier statements in this thread, Then you seem to have a problem with elementary logical reasoning. Your above statement (about "re-inventing the wheel AND worrying about dependency collisions") is totally illogical nonsense. Just one issue: MacOS application have always been far more compact (both on disk and in RAM) than comparable Windows or Unix counterparts. "Despite" the fact that they where GUI applications since MacOS 1.0. No one has to "re-invent" any more wheels to develop a MacOS X application than he has to do for a Windows or Linux application. In fact, usually, there are less wheels to re-invent for MacOS X. Next: The self-contained nature of applications is obviously exactly what *eliminates* dependency collisions. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> > Linux was made by geeks who didn't have a clue of ergonomics for > > screenworkers and didn't care to get one. > > I can only repeat what you said earlier: > > "You should get a clue in stead [sic] of just fantasizing up > assumptions based on ignorance." > > I daresay that Linus Torvalds spends more time in front of a computer > screen than most 9 to 5 "screenworkers". He's a developer, not a usual screenworker. > By the way, you keep replying to people, and quoting them, but > deleting their name. Please leave the attribution in place, so we > know who you are replying to. That's what the "References:"-Header is there for. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> I've worked with both. Quite honestly, I really wish that other > operating systems had gone down this route. MS didn't possibly to make > it harder to steal software, >From the perspective of the computer-literate, proficient screenworker, MS always got and gets everything completely wrong. > and Unix...well, *nix has the concept of the "distribution" that will > manage all of this for you. We all know the problems that this > causes. Linux was made by geeks who didn't have a clue of ergonomics for screenworkers and didn't care to get one. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> > Because on such operating systems, each and every application is an > > entirely self-contained package that doesn't need any "packages" or > > "installers" to use it. > For people who have never used such a system it's probably difficult > to see the advantages. That's the whole point. The problem is that the ones who "decide" (well, they pretend to, but actually can't, because they don't know the alternatives) are always people who are "not even clueless". I.e. they are totally clueless, *and* psychotically self-convinced of their omnicompetence. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> > Thankfully, all actually user-friendly operating systems (MacOS, > > TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the > > bottomless cesspit of "package management" and/or "installers". > > > > Because on such operating systems, each and every application is an > > entirely self-contained package that doesn't need any "packages" or > > "installers" to use it. > > You mean everyone has to reinvent the proverbial wheel AND worry about > dependency collisions? Yeah, that's a heavenly thought. You should get a clue in stead of just fantasizing up assumptions based on ignorance. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
> Windows and OS X users, sadly, miss out on the power of an integrated > package manager. Thankfully, all actually user-friendly operating systems (MacOS, TOS, RiscOS, probably AmigaOS, MacOS X) spare(d) their users the bottomless cesspit of "package management" and/or "installers". Because on such operating systems, each and every application is an entirely self-contained package that doesn't need any "packages" or "installers" to use it. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Create flowcharts from Python
> Is there a library for Python that can easily create flowcharts using > a simple API? Graphviz (->TikZ->LaTeX->PDF) > But the users want to see this as a visual flowchart too. It would > be the best to have it automatically arranged; or at least open it an > editor so they can move the nodes and see how they are connected. I think Dia and yEd can im-/export dot (Graphviz format) and/or TikZ. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Is MVC Design Pattern good enough?
> > The most intuitive approach to database applications would be:
> >
> > http://en.wikipedia.org/wiki/Naked_objects
> > http://www.nakedobjects.org/
> >
> > [...]
> >
> > Unfortunately, there's no Python framework (yet?) that implements
> > this design.
>
> It could be a blessing in disguise. Too often people encumber simple
> concepts with frameworks.
The point is that frameworks (for this kind of application) (should)
allow people who are not computer scientists but domain specialists to
implement useful applications.
Which makes sense since especially in the domain of typical "business"
applications, since it's much easier to teach a reasonably
computer-literate domain specialist a programming language that's
user-friendly such as Python and a user-friendly framework, instead of
teaching a software developer the knowledge of the application domain.
So the computer scientist(s) designs and implement the framework, and
the domain specialist(s) implements the domain-specific application
logic.
The "naked objects" concept makes this especially intuitive since all
the domain-specific application logic is in the "business objects". And
since you don't need to implement anything else besides these to get a
functional application.
Unfortunately, the developer of the naked objects framework has chosen a
language that is pretty bad in terms of "usability" for domain
specialists; Java. And it sucks for GUIs, too. C# isn't much better,
expecially since it's limited to a pathologic non-operating system.
Python could demonstrate the interest of this concept much better than
the existing Java and C# implementations, not only because it's much
better suited to non-computer scientists, but also because it's more
cross-platform than C# and better for GUIs than Java.
Another important aspect of "naked objects" is about reducing the
amount of code that needs to get written to implement a given
functionality. Python is definitely more efficient here than Java and
C#.
In short; Python would be the perfect choice of implementation language
for such a ("naked objects") framework.
Unfortunately with all that hype about "web applications", there is
little focus today on (frameworks for) applications that are actually
useful for end-users who have to get real work done with the computer.
Sincerely,
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is MVC Design Pattern good enough?
> I had developed many database business applications using MVC design > pattern with different programming languages like PHP, Java EE, > VB.NET, C#, VB 6.0, VBA, etc. All of them defined the Model layer as > the data management of the application domain and business logic > implementation. I ready don’t understand what the data has to do with > applications business logic. Nothing? Can we implement the > application business logic in another layer? Yes or no? Why? Explain? The most intuitive approach to database applications would be: http://en.wikipedia.org/wiki/Naked_objects http://www.nakedobjects.org/ The original "Inventor" of MVC once declared that this concept matches his intentions a lot better than the very vast majority of MVC implementations. Unfortunately, there's no Python framework (yet?) that implements this design. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
> With python I got IDLE, but I am not very comfortable with this. > > Please suggest, if we have any free ide for python development. There are a lot of IDEs for Python. One classic is WingIDE. Available for free is a "101" edition. Runs on all major operating systems. Implemented itself in Python. An editor that's completely implemented in Python is Editra. With plugins you can turn it into an "almost IDE" as well. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Math
> Does Python have good mathematical capabilities? SAGE: http://www.sagemath.org/ Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: [OFF-TOPIC] How do I find a mentor when no one I work with knows what they are doing?
> Things I'm interested include contributing to both Python and Django, > database design and data modeling, Django is made by people who definitely don't know what they're doing. https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys Open the index to any half-decent database design textbook, look for the term "overlapping foreign keys" and learn why surrogate keys are a non-starter. One answer to the subject line would be: Learn to judge the competence of people by asking a few "litmus" questions. The above mentioned issue is one personal "litmus" question I ask anyone who pretends to have a clue of database design and database applications. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Examples of modern GUI python programms
> Id like to ask.. do you know any modern looking GUI examples of > windows software written in python? Something like this maybe: > http://techreport.com/r.x/asus-x79deluxe/software-oc.jpg (or > hopefully something like this android look: > http://chromloop.com/wp-content/uploads/2013/07/Skype-4.0-Android-screenshot.jpg). These are textbook examples of totally anti-ergonomic gadgetcrap for gamekiddies. Judging from the example screenshots on their website, Kivy might be adequate. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: python first project
> i am programming a system that will be giving details about finance, > purchase(bills pending bills and paid bill), employees record and > salary details, warehouse records. > > That is just all i intend to do this all on one GUI application > window and to make it to be able to keep records for all the > transaction which has been done inputted. If "keeping records" implies significant amounts of data, then this is a typical case of a database application. There are a couple of Python frameworks for this kind of application: using wxPython: Dabo http://www.dabodev.com (already mentioned) Defis http://sourceforge.net/projects/defis/ (Russian only) GNUe http://www.gnuenterprise.org/ using PyQt: Pypapihttps://pypi.python.org/pypi/PyPaPi/0.8 Camelot http://www.python-camelot.com/ Qtalchemy http://www.qtalchemy.org/ Thyme http://clocksoft.co.uk/downloads/ Kexi http://www.kexi-project.org/ using PyGTK: SQLkithttp://sqlkit.argolinux.org/ Kiwi http://www.async.com.br/projects/kiwi/ Glom http://www.glom.org Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Using multiple ORMs? - And SQLalchemy vs Pony vs Peewee vs stdnet vs …
> Thanks for all suggestions, Two essential criteria: If an ORM only allows 1:1 mapping between classes and tables à la "active record", then it's entirely pointless. And if an ORM allows only surrogate keys, then its developers don't have a clue of databases or they don't give a darn. Or both. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> > On an actual operating system, the attitude of the developers (do > > they actually care or just don't give a darn) is *the* critical > > issue for end-user productivity. If a developer makes a statement > > such as of "just get a faster computer" or "just get more RAM", > > then (s)he probably doesn't give darn. C++ applications, just like > > Java applications, tend to leak horrible amounts of memory these > > days, just because the vendors/developers don't care. > > I'll note that Python core developers do care about memory leaks. And that's a really good thing. But unfortunately, these days, it's rather the exception. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> > With Windows systems, I waste something like 90% of my work time > > waiting for that system to stop "Not Responding". > > > > And no, it's not a matter of hardware. > > Something is wrong then. You bet. > Windows has its issues, and it does slow down over time as cruft in > the system accumulates. And Windows XP is getting slower and slower > due to a bug in the automatic updates service, but in general, but > your experience with Windows is not normal. With Windows it *is* "normal". An experienced software developer once even explained the reason to me. When a single process on Windows does I/O, then the system essentially falls back to "single tasking". Or (non-)"cooperative multitasking" at best, depending on how dissocial the developer of that process is. > I managed hundreds of Windows workstations in my previous > life and I did not see this occur with any regularity. Well, because you only "managed" those computers, you never tried to accomplish actual *work* with them. > So something is wrong with your setup. Maybe its time for a > re-install? Virus or malware? Windows itself is the problem. > Or maybe you need to upgrade to Windows 7? Won't change anything. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> > I've never heard C syntax reviled quite so intensely. What syntax > > do you like, out of curiosity? > > Pascal, Python, if written by someone who uses semantic identifiers > and avoids to use C(++)/Java-isms. I've seen Eiffel as well (without > understanding it) and it didn't look ridiculous to me. Nor did a recent dialect of Cobol (since someone else mentioned it) horrify me at first sight to the point all those C-derivatives do. I also get to use SQL a bit (instead of those "query builders" that I consider as garbage), although that's just for databases of course. Verbosity is definitely A Good Thing. In fact, thinking of it, a really good language should imho *require* verbosity (how about a *minimum* length - or maybe even a dictionary-based sanity check - for identifiers?), since that already keeps all those lazy morons away who think that "shortcuts are cool". Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> > All Java GUI frameworks I know of are ridiculous garbage. > > > > Not only that Java per se is obscenely fat (and unresponsive), but > > the GUI frameworks leak like bottomless barrels and the look and > > feel is so hideous that I would say from personal experience with > > numerous Java applications that there is little that's worse for > > user productivity than a Java application running on Windows. Well, > > a "web application" might top it. > > Pray tell is there anything that is not ridiculous garbage or is your > computer so hopelessly broken that everything fails on it? You've > already dissed on Windows, Firefox, the web, Java. If Windows, Firefox, "the web" and Java are "everything" that you know of in terms of IT, then I pity those poor people who have to succumb to your "competence". > Surely Python must suck also because it's slow and interpreted. I don't draw skewed parallels. Instead I base my judgments on my personal experience from those decades of screenwork for various tasks with various applications on various systems, correlated with the experience of all those knowledgeable people I've learned to know during that time, as well as logical deductive thinking. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> I find it frustrating that Pythonistas shy away from regex as much as > they do. I find regular expression syntax frustrating. >;-> As long as I have the choice, I still prefer syntax like e.g. VerbalExpressions. That's made for actual humans like me. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: request for guidance
> I am a novice who is really interested in contributing to Python > projects. How and where do I begin? You're looking for work? Try: https://wiki.python.org/moin/PythonProjects http://www.python.org/about/apps/ https://wiki.python.org/moin/Applications http://en.wikipedia.org/wiki/List_of_Python_software And pick whatever fits best with your interests and skills. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> I was also taught C as an undergrad but having already learned Java, C > and C++ before arriving at University I found the C course very easy > so my own experience is not representative. Many of the other students > at that time found the course too hard and just cheated on all the > assignments (I remember one students offering to fix/finish anyone's > assignment in exchange for a bottle of cider!). The problem with the C class wasn't that it was "hard". I had passed my Pascal class, which taught nearly exactly the same issues with "straight A"s before (without ever having writeen any source code ever before). And by standard cognitive testing standards, I'm not exactly considered to be an idiot. The only issue for me was to figure out how to do in C what I already knew in Pascal. And I had to waste a *lot* more time and mental effort to mess with that language than it took for me to learn *both* the basics of programming per se *and* Pascal in the first class at my home university. C is just a kafkaesque mess invented by a sadistic pervert who must have regularly consumed illegal substances for breakfast. Its only reason to exist seems to be that apparently it's ridiculously easy to implement a "compiler" for it. Although, as a professional developer once told me, most C compilers are garbage. One student in the C class (who had been doing software development for years before he came to university) jokingly passed around samples of "valid" C code by email. Most of them looked like uuencoded binaries (this was in the early-to-mid 90s), but they all compiled and produced an output. Except that *no one* (including professors) was able to predict the output without actually running the compiled code. In the classroom lectures parallel to the C exercises, the professor spent most of his time explaining what *not* to do because... Heck, why does a language provide features resp. allow their use in ways that are known to be bottomless cans of worms. > These types of problems are compounded by the fact that the current C > course uses automated marking so a program that produces the correct > output gets full marks even if it is terribly written and the student > entirely misses the point - another thing about this course that > definitely needs to change. In our classes, when a program was correct, but e.g. you used just *one* single non-semantic identifier (such as an "i" for a loop index), you got *automatically* zero points for that exercise. Other absolutely mandatory requirements were about minimum commenting etc. Less comment lines than code was very likely to yield zero points for that exercise as well. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> On Sun, Dec 15, 2013 at 4:33 PM, Wolfgang Keller > wrote: > > And besides, again, a commercially licensed PyQt itself isn't *that* > > expensive. > > > The cost of a commercial PyQt license for a single developer is £350 > > (GBP). You may pay in either US Dollars, Euros or GBP. I didn't write the second paragraph. Please learn to quote, thanks. > (£420 incl. VAT for UK and select EU entities) For a commercial developer that doesn't appear much to me. I know Qt applications that cost ~100.000 EUR per seat. Others are so valuable that they simply aren't sold at all. Wingware since recently uses PyQt and their prices don't seem to have skyrocketed since the migration from PyGTK. > > one [license] per developer > > For some people, it might be a lot. Why waste money on something, > that has an almost-identical free-for-everyone version? (which also is > easier to install, BTW) Because PySide is *far* from identical. > > PyQt does not include Qt itself. You must also obtain an > > appropriately licensed copy (either the commercial version from > > Digia or the LGPL version from the Qt Project). Thanks again for learning to quote correctly. I did not write this paragraph. > So, you have four options: If you need something that's actually supported, Pyside (currently) doesn't look like a credible option to me. And for "home users", education etc., the GPL version of PyQt seems perfect to me. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> > It's not just the abysmally appalling, hideously horrifying syntax. > > At about everything about C is just *not* "made for human beings" > > imho. > > I've never heard C syntax reviled quite so intensely. What syntax do > you like, out of curiosity? Pascal, Python, if written by someone who uses semantic identifiers and avoids to use C(++)/Java-isms. I've seen Eiffel as well (without understanding it) and it didn't look ridiculous to me. In short, syntax that contains the strict minimum of "special" characters (delimiting lists etc. with brackets is ok to me), and almost exclusively human readable words. Although, if you push it to the extreme; Applescript is nice to read, but much less nice to write imho... :-/ C, C++, Java, Javascript, PHP, Perl etc., however, are just unspeakable . BTW; Yes, I do *hate* those C(++)-isms (or Java-isms) that have started to sneak into Python in the past ~10 years. Using e.g. == for comparisons is just braindead. Use := for assignments instead, because that's mathematical syntax. And that "@" for decorators is, well, who proposed it? I'd like to cut off all his fingers with a bolt cutter. The same for people who use augmented assignments, "syntax shortcuts" or abbrvtd idtfrs. Ship them all to Fukushima, one way, no return ticket. Learn to touch-type, get an editor with decent syntax completion or just stop wreaking havoc to the world economy with your laziness. Code is read a hundred times more often than it is typed. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> Please check JYTHON and those ready-for-novice GUI tools in java. All Java GUI frameworks I know of are ridiculous garbage. Not only that Java per se is obscenely fat (and unresponsive), but the GUI frameworks leak like bottomless barrels and the look and feel is so hideous that I would say from personal experience with numerous Java applications that there is little that's worse for user productivity than a Java application running on Windows. Well, a "web application" might top it. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> The other thing, specially if you would make a customer project, I > don't know how to pack the app written in python in an installer. If you want your application to be actually user-friendly, you make it available as an installer-less zip archive. It works with Python applications, no matter whether they use PyGTK, wxPython or PyQt. > Perhaps I am wrong, and you could give me in exchange an advise ?! Python is probably the "best" language for application implementation in general. Anything that would really need to be faster than python itself allows can easily be implemented in "compiled" Python à la Pyrex et al. > I also believe in performance. An application written in C++, can be > compiled easily on the target platform (like on windows systems) with > it's native compiler. > How would it be with wxPython ?! It isn't an issue. With that pathological non-operating system Microsoft (Not Responding), as soon as your application has to do any I/O, or if there's any other process (virus scanner, file system indexer) running that does I/O, any computer will be unusable for productive work anyway. On an actual operating system, the attitude of the developers (do they actually care or just don't give a darn) is *the* critical issue for end-user productivity. If a developer makes a statement such as of "just get a faster computer" or "just get more RAM", then (s)he probably doesn't give darn. C++ applications, just like Java applications, tend to leak horrible amounts of memory these days, just because the vendors/developers don't care. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> For example Firefox implements its entire GUI in
> Javascript using XML GUI definitions.
Which has made Firefox essentially unusable because it will fall into
koma ("Not Responding") for minutes upon almost each and every
mouseclick. Unfortunately I don't know any significantly better
alternatives.
> And all modern web apps are a combination of many languages and
> domains, most of which are "compiled" in the traditional sense.
"Web apps" are the most efficient way I know of to make users who have
to get actual work done as inefficient as possible. It's especially an
extremely effective way, together with Firefox's "responsiveness", to
make any operating system as obscenely unusable as Windows.
Sincerely,
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> Python is sooo slow when it waits for the human. With Windows systems, I waste something like 90% of my work time waiting for that system to stop "Not Responding". And no, it's not a matter of hardware. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> > And ever after that experience, I avoided all languages that were > > even remotely similar to C, such as C++, Java, C#, Javascript, PHP > > etc. > > I think that's disappointing, for two reasons. Firstly, C syntax isn't > that terrible. It's not just the abysmally appalling, hideously horrifying syntax. At about everything about C is just *not* "made for human beings" imho. It's just an un-language that gets at about everything wrong. Sort of like Microsoft's products. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> I think PyQt is slowly being pushed aside in favor of PySide, which is > more license-friendly for use in closed or open projects. I would > recommend using PySide unless PyQt is a requirement for your project. Except the issue that Pyside always seems to lag a bit behind Qt releases, while PyQt usually supports more recent releases of Qt. Besides that, according to what I've been reading on the PyQt mailing list, support is impressive. The developer often fixes issues over night, if there actually are any. And besides, again, a commercially licensed PyQt itself isn't *that* expensive. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI:-please answer want to learn GUI programming in python , how should i proceed.
> GUI:-want to learn GUI programming in python , how should i proceed. > > There are lots of book here so I am confuse which book i should > refer so that i don't waste time . It depends on what you want to do with the GUI, since there are many different GUI frameworks for Python. E.g. If you absolutely need to run your applications on MacOS X, then PyGTK is probably not the best choice. WingIDE, a popular IDE, has been recently ported to PyQt, apparently for this reason. Besides, PyGTK itself seems to be "shelved", PyGObject now (since GTK 3) seems to be the "canonical" way to implement GTK GUIs in Python. Tkinter is a bit "special" to use since it's not just a library, but uses some kind of RPC. It seems that "look and feel" have been greatly improved lately. wxWidgets (wxPython) recently (since 2.9/3.0) got support for Cocoa, it's native on the Mac. It's quite slim, but seems to be a "moving target" API-wise, since the developers are not shy from breaking compatibility. Is it compatible with Python 3 yet? PyQt looks native everywhere, but it might be a bit overweight, depending on what you want to do and where your applications need to run. And then there's the licensing issue, since PyQt, unlike Qt itself, is not available under LGPL afaik. For closed-source commercial applications, there seems to be a way to use a commercially licensed PyQt (much less expensive than Qt itself) together with LGPL-Qt however. Pyside would be a LGPL alternative to PyQt, but it doesn't seem to be as up-to-date as PyQt. And then, there are even more frameworks, such as Pygame, PyGUI, etc And each of these frameworks has dedicated mailinglists. Personally I found it difficult to use any of the "wrapped" C++ frameworks without being able to understand the documentation made for C++. :-( Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> I'm particularly interested to know if anyone can share experience of > switching to teaching Python as a first programming language in a > similar context. A written up case study that I could circulate among > the relevant staff would be especially useful. Just one experience from the "other" (student's) side. When I started to study engineering science in 1991, Pascal was the "first language" at the university in question (there were no programming classes at highschool over here at that time yet). The class was quite motivating and taught me some essential basics, I think. Although issues such as object-orientation or event-based (GUI) programming were not even mentioned, which is something that I'm desperately missing today. When I went to a different university (in 1993), still in engineering science, they used C as the "first language" in the class there. The result was that I tried (and succeeded) to pass that class with the strict minimum of effort possible and deliberately forgot everything that I had to learn about C as quickly as possible afterwards. I was a "very good" student back then otherwise, so this was not due to general laziness. What that class has taught me, essentially, was to *hate* C. And it was not an issue of bad teachers. And they didn't mean to make me hate C, after all, it was them who had chosen that language. I never ever used C for anything (outside of that class). And ever after that experience, I avoided all languages that were even remotely similar to C, such as C++, Java, C#, Javascript, PHP etc. In numerics classes and for research projects, I had to learn and use Fortran, which was easy after the introduction with Pascal. The teachers who taught me Fortran easily were the same as those who made me hate C. Then, I accidentally got in touch with Python (in 1994 iirc) and thought it was interesting and useful. In fact Python is the only programming language that I ever learned without being obliged to do so. And the only one that I keep using whenever I have the choice. Since then, the university that once used C as a "first language" has switched to Python. Which is a good thing, imho. If I had had to learn the basics of programming with C instead of Pascal, I most certainly would have avoided anything even remotely connected to programming ever since, even "office automation" through scripting (which is what I use Python for today). Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Access database - GUI - Python - I need architectural advice
> I wish to develop a database application with a lot of specific > functionnalities dealing with sound files. > > I have developped an Access prototype and run into a first problem : Access is not a database, it's a data shredder. And for the GUI part; it only works on that pathologic non-operating system called Microsoft (Not Responding). Use PostgreSQL instead and one of these frameworks with Python: using PyQt (& Sqlalchemy): Qtalchemy: www.qtalchemy.org Camelot: www.python-camelot.com Pypapi: www.pypapi.org using PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi using wxPython: Gui2Py: code.google.com/p/gui2py/ Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python GUI?
> As complexity rises, though, I'd rather just code the creative parts > of things, and not busy-code, which is what gui code becomes. Much > of it is boiler-plate, cut and pasted, etc. If much of the code for a GUI is boiler-plate, busy-code etc. than I would suggest that the framework is not really as efficient as it should be. In fact that's one of the issues I still have with Python: The language in general is very efficient, allows to do a lot with very little code. But all GUI frameworks that I had a look at seem to be not "pythonic" at all in this regard. Except for PyGUI maybe, but that's far from being as extensive as wxPython or PyQt. So for GUI applications, Python doesn't seem to have any advantage over #§$%&! like C++ etc. concerning code efficiency. X-( Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
> Every time you go on the Internet, you download other people's code > and execute it. Javascript, Flash, HTML5, PDF are all either > executable, or they include executable components. That's why I deactivate all of these by default. And why I *hate* so-called "web designers" who *require* activation of such fancy flashy nonsense gadgets. PDF files are an exception since PDF was originally designed as a "safe" subset of Postscript (postscript viruses had been demonstrated). Now Adobe has jeopardized this by allowing embedding of Javascript in PDF files (but that as well is deactivated by default for me). Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Can I trust downloading Python?
> Definitely get the latest version (currently 3.3, soon 3.4). Python > keeps getting new features and improvements. Python scripts or applications might not be compatible with Python 3.x and require 2.x instead. Sincerely, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
> I am seeking comments on PEP 450, Adding a statistics module to > Python's standard library: I don't think that you want to re-implement RPy. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Python development tools
> Also, I will use GUI interface for Python. What kind of widget > toolkits do you recommend? I know there are GTK+ and Qt. wxPython, PyGUI... Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> Okay... how long does a round-trip cost? With a protocol that wasn't made for the purpose (such as HTTP) and all that HTML to "render" (not to mention javascript that's required for even the most trivial issues) - way too long. > Considering that usability guidelines generally permit ~100ms for > direct interaction, That's "generous". A proficient user with a responsive application can easily outpace that. 100ms is definitely a noticeable lag. Even I feel that and I don't use touch-typing to use the GUI. 50ms might not be noticeable, but I don't have the skills myself to test that. > (Magento, a PHP-based online shopping cart system, took the better > part of a second - something in the order of 700-800ms > - to add a single item. And that on reasonable hardware, not a > dedicated server but my test box was certainly not trash.) That's not a question of hardware. Just like with MS (Not Responding). > That's the entire round-trip cost. The queries from Sikorsky to > Yosemite involve three computers (the client, the server, and the file > server), and is completed in under 30 milliseconds. I am talking about applications that actually do something. In my case, database applications. A PostgreSQL transaction is supposed to take at most 25ms to complete (anything above is generally considered an issue that needs to be solved, such as bad SQL), *server-side*. That leaves you another 25ms for the entire network protocol (the pgsql protocol, whatever it is, was designed for the purpose, unlike HTTP) *and* the client-side application logic, including the GUI "rendering". Qt is already quite sluggish sometimes, don't know why. GTK and wxPython "feel" swifter, at least on an actual *operating* system. MS (Not Responding) is definitely incapable to allow applications anything remotely close to "responsiveness". Minute-long lockups with frozen cursor are "normal". > That still gives you 70 milliseconds to render the page to the user, Forget that. 25ms for client-server (pgsql) network protocol, client-side application logic *and* GUI. With a "web" application that would have to include "application server"-side application logic, *and* generation of HTML (and javascript), *and* HTTP protocol *and* HTML "rendering" *and* client-side javascript. Won't work. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> I share your passion for empowering a human operator to complete and
> submit a form as quickly as possible. I therefore agree that one
> should be able to complete a form using the keyboard only.
This is not just about "forms", it's about using the entire application
without having to use the mouse, ever.
> Do you have strong views on which is the preferred approach.
Use a decent database RAD desktop (non-web) GUI application framework
which uses client-side application logics. "Validation" of input will
then be essentially instantaneous. Unless you run the client on that
pathological non-operating system MS (Not Responding), obviously. I've
posted a corresponding list of frameworks available for Python multiple
times already on this group:
using PyQt (& Sqlalchemy):
Qtalchemy: www.qtalchemy.org
Camelot: www.python-camelot.com
Pypapi: www.pypapi.org
using PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi
using wxPython:
Gui2Py: code.google.com/p/gui2py/
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org
Server-roundtrips required for simple user interaction are an absolute
non-starter for productivity applications. No matter whether in a LAN
or WAN. If you want a responsive application you have to de-centralise
as much as possible. Perfect solution would be if Bettina Kemme's
Postgres-R was available for production use, then even the persistence
could run locally on the client with asynchronous replication of
all clients ("peer to peer").
Sincerely,
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> > A "touch-type" GUI is a "must have" for any application that's > > supposed to be used productively. The mouse is nice to "explore" a > > GUI or for occasional/leisurely use, but once you use an > > application daily to earn your living, it's a hopeless roadblock > > for productivity. > > You have seriously underestimated the power of the combined > keyboard+mouse interface. As someone who has started to use computers with the Atari ST and later the Mac, and as someone who has never become proficient himself with any of the various Unix shells (besides that I had to learn to *hate* any version of MS DOS or MS (Not Responding)), I certainly don't underestimate the value of the mouse. But could it be that you have never seen an actually proficient user of a typical "enterprise" application (ERP, MRP, whatever) "zipping" through the GUI of his/her bread-and-butter application so fast that you can not even read the titles of windows or dialog boxes. Obviously, this won't work if the client runs on this pathological non-operating system MS (Not Responding), much less with "web applications". Oh, and btw; SAP is a particularly illustrative example for the horrible response time behaviour of applications with centralised application logic. They call it "hour-glass display program" over here, "SanduhrAnzeigeProgramm" in German. > > As is the "response time" behaviour of "web applications". > > On a LAN, with a proper back-end, I can get instant response from a > web app. I have been involved as "domain specialist" (and my input has always been consistently conveniently ignored) with projects for web applications and the results never turned out to be even remotely usable for actually productive work. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> > A GUI that can not be used without taking the ten fingers off the > > keyboard is indeed entirely unusable for any half-proficient > > screenworker. And anyone doing actual productive screenwork every > > day for more than just a few months will inevitably (have to) get > > proficient (unless completely braindead). > > My ten fingers stay on my keyboard, which looks somewhat thus: > > http://www.xbitlabs.com/images/mobile/lenovo-thinkpad-t61/keyboard.jpg > > See the red dot in the middle? Mouse. I didn't mean "trackpoints" or similar devices, but full keyboard "navigation" of the entire GUI through shortcuts etc. A "touch-type" GUI is a "must have" for any application that's supposed to be used productively. The mouse is nice to "explore" a GUI or for occasional/leisurely use, but once you use an application daily to earn your living, it's a hopeless roadblock for productivity. As is the "response time" behaviour of "web applications". Besides that pathological non-operating system MS (Not Responding), btw. "No cursor animation ever" is an absolute "must have" requirement for productivity applications. > THIS is a professional programmer's workspace. :) And by "screenworkers" I didn't refer to programmers. Those people rarely have to use the stuff that they implement. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> >> suppose I now want the app natively on my phone (because that's all > >> the rage). It's an iPhone. Oh. Apple doesn't support Python. > >> Okay, rewrite the works, including business logic, in Objective C. > >> Now I want it on my android phone. > > > > Those are gadgets, not work tools. > > As a professional programmer I'm afraid you're going to soon find > yourself out of work if you really see things that way. As a "domain expert", I come from the end-user side of "enterprise applications" and again; those are not tools for screenworkers to get actual work done, but consumer crap for fad-driven gadget-addicted kids (regardless of nominal age). > I honestly used to feel that way about graphical user interfaces. A GUI that can not be used without taking the ten fingers off the keyboard is indeed entirely unusable for any half-proficient screenworker. And anyone doing actual productive screenwork every day for more than just a few months will inevitably (have to) get proficient (unless completely braindead). Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> What is "screenwork"? Actually productive work of significant intensity at a computer screen. As opposed to leisurely "clicking around" like managers, administrators or home users (gaming, "webbing",...) do. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> Please give me an example of a "suitable transport layer for a RPC > protocol". I won't give you an example, but just some very basic criteria: - It must be very efficient for very small "datagrams" - It must provide connections - For asynchronous programming it must provide for callbacks No RPC-over-HTTP protocol that I know of does this. Besides, no one needs RPC just to logically separate GUI and application layer. And between application logic and database, you use the native database API for the RDBMS in question, of course. The whole idea to centralise application logic (and even the GUI with "web applications") is backwards, it dates from the 70s/early 80s when desktop computers weren't able to run application logic. Today, to make an application responsive (minimise latencies and maximise throughput), it's just obvious to *de*-centralise as much as possible. In fact, if Postgres-R was available for production, you could even distribute the persistence and run an entirely "serverless" application. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> HTTP handles that just fine, with your choice of XML, And XML is definitely not suitable as a marshalling format for a RPC protocol. XML-over-HTTP is a true cerebral flatulance of some hopelessly clueless moron. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> Your back end exposes services and business logic, and your front end > can be in HTMLv5 and Javascript, or QtQuick, PyGTK, or Visual > Studio. If you do need a native interface, it's a heck of a lot > easier to rewrite just the frontend then the entire stack. Any decent database CRUD framework will allow to implement the application model as "behaviour complete" domain objects, with a persistence layer totally independent from the GUI layer. In many Python RAD frameworks, this is done using SQLalchemy. > Who cares how the RPC is done; As an end-user I do care for how much an application makes we watch the cursor animation. > that's an implementation detail. HTTP does happen to work well > though. Why do you say it is not suitable? Because from personal experience I know too well that it does definitely not "work well though". > suppose I now want the app natively on my phone (because that's all > the rage). It's an iPhone. Oh. Apple doesn't support Python. > Okay, rewrite the works, including business logic, in Objective C. > Now I want it on my android phone. Those are gadgets, not work tools. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> > Both the concept and actually implemented examples of so-called "web > > applications" prove that they are just plain garbage and hopelessly > > unusable for anything remotely resembling actual screenwork. > > > > HTML forms may be at best useful for "web shops", but for actual > > screenwork, HTML is not a valid GUI, no matter how much javascript > > you add to it. > > All depends on your requirements. Obivously, if your requirements are to be compliant with latest IT management fads and to not give a darn for end-user productivity or even legal requirements for screen workplace ergonomics... > For the Yosemite Project, I wanted the networking aspect, so the web > browser UI was a good one. >From the description this looks like a simble database CRUD application. Somethign like that is definitely easier to implement and to deploy and a *lot* more functional with any of the RAD frameworks available for Python. And just like HTML never was a valid GUI framework and never will be one, HTTP will never be a suitable transport layer for a RPC protocol. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> But there's another option that is available to every platform and > (practially) every high level language: the web browser. Make your app > serve HTTP and do up your UI in HTML5/CSS3 - your facilities are > pretty extensive. Plus you get networking support for free! Obviously > this option isn't for everyone, but don't discount it out of hand. Both the concept and actually implemented examples of so-called "web applications" prove that they are just plain garbage and hopelessly unusable for anything remotely resembling actual screenwork. HTML forms may be at best useful for "web shops", but for actual screenwork, HTML is not a valid GUI, no matter how much javascript you add to it. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> I know this may sound a silly question because no one can see the > future. But ... > Do you think tkinter is going to be the standard python built-in gui > solution as long as python exists? "Standard built-in" maybe, but by far most people who need a GUI for an actual application will keep using something else. > I couldn't help but wonder if wx or PySide receives better py2 and py3 > support, or anything else that prevent > them from getting into the standard python distributions, whether or > not this scene could start to shift ... Didn't Pyside have serious trouble recently, requiring a reanimation of the project? > I believe this "which one of tkinter, wx, qt, is the best gui toolkit > for python" flame war has been going on > for ages. If (Py)Qt wasn't so freaking fat, it might be the best. If wxPython had a more pythonic (and stable?) API, it might be the best. If PyGTK was more native on Windows and native at all on MacOS X, it might be the best. If PyGUI was more extensive, it might be the best. > This worries me very much about whether I should start a gui app > using python. What other open-source cross-platform programming language choices do yo have. Java? For GUIs? Excuse me while I vomit. C++? As a language for human beings? Oops, I have to throw up again. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Future standard GUI library
> Do you think tkinter is going to be the standard python built-in > gui solution as long as python exists? > >>> > >>> AT the moment, there is nothing really comparable that is a > >>> realistic candidate to replace tkinter. > >> > >> FLTK? (http://www.fltk.org/index.php) > > > > tkinter is the Python wrapper of the tk library, just as wxpython > > is the python wrapper of the wx library. I do not see a py-fltk > > wrapper. > > It exists, but it's really old. > > http://pyfltk.sourceforge.net/ And it's imho definitely not "native" (in terms of "look and feel") on *any* operating system, not even on Linux. In fact it's SGI's Irix Forms re-implemented, afaik. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE for GUI Designer
> Well, I usually use the Qt Designer and it does work well for me. > > It generates a .ui file with it which has to be passed to pyuic to > generate the actual Python code Wow. Even one more step than with code generation directly from the GUI builder. Clumsy, tedious, static. Cocoa's Interface Builder shows how to do it even though Objective-C is a *compiled* language, unlike Python. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE for GUI Designer
> Guys, is this, I wonder if there is an IDE with native support for the > development of GUI's A decent Python IDE would probably integrate well enough with any decent GUI builder. If there was one (decent GUI builder). Unfortunately there's afaik currently no GUI builder available for any of the Python GUI frameworks that actually makes use of the dynamic interpreted nature of Python (in a way comparable to Cocoa's Interface Builder or the Visualworks Smalltalk IDE). They are unfortunately all just conceived following the clumsy tedious static C++-ish code-generation method. X-( Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the easiest Python datagrid GUI (preferably with easy database hooks as well)?
> >> Will look at Pypapi and SQLkit. > > > Did look: SQLkit needs Python 2. Personally I would be more concerned about the apparent end-of-life of PyGTK. > Pypapi, from the link you gave: "The new release of PyPaPi is written > in Java. You can find more info in the official site." On this > official site - http://www.pypapi.org/ - I can't find anything at all > about using PyPaPi with Python. Unfortunately I have lost the URL for the documentation (tutorial etc.) on the Python pages at www.pypapi.org. I'm afraid you'll have to ask the author. Pypapi, which is in production use in version 0.8, had been re-implented in Java for some reason (paying customer?), and the design changes have been back-ported to the Python implementation, yielding the version 0.9, which is considered beta. I liked the approach of this version, because it essentially only requires you to write the declarative Sqlalchemy model, layout the forms in Qt Designer and that's it. At about as little hand coding as possible. If you don't mind source code of an example application being essentially the only documentation, you can also look at Qtalchemy. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the easiest Python datagrid GUI (preferably with easy database hooks as well)?
> As far as Dabo is concerned, at the moment I just have to know how to > spell "crash" ... Seems like someone is in desperate need of what they call "release management". X-( Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the easiest Python datagrid GUI (preferably with easy database hooks as well)?
> Very helpful collection, only one open question: which of them work > with Python 3? No clue, sorry. Given how many other modules are not yet compatible with Python 3, I haven't investigated that yet. wxwidgets/wxPython already has *just* made the switch to Cocoa (with 2.9) when Carbon support was dropped by Apple, and I don't have a clue about the future of PyGTK (last update 2011, seems to have been replaced by PyGObject). > Will look at Pypapi and SQLkit. Frustrated with Dabo? Why? Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: What's the easiest Python datagrid GUI (preferably with easy database hooks as well)?
> I want to write a fairly trivial database driven application, it will > basically present a few columns from a database, allow the user to add > and/or edit rows, recalculate the values in one column and write the > data back to the database. > > I want to show the data and allow editing of the data in a datagrid as > being able to see adjacent/previous data will help a huge amount when > entering data. > > So what toolkits are there out there for doing this sort of thing? A > GUI toolkit would be lovely (allowing layout etc.) but isn't > absolutely necessary. > > I'm a reasonably experienced programmer and know python quite well > but I'm fairly much a beginner with event driven GUI stuff so I need > a user friendly framework. This is becoming an FAQ. The currently available (non-web) database application development frameworks for Python are: using wxPython: Dabohttp://www.dabodev.com Defis http://sourceforge.net/projects/defis/ (Russian only) GNUehttp://www.gnuenterprise.org/ using PyQt: Pypapi https://pypi.python.org/pypi/PyPaPi Camelot http://www.python-camelot.com/ Qtalchemy http://www.qtalchemy.org/ Thyme http://clocksoft.co.uk/downloads/ Kexihttp://www.kexi-project.org/ using PyGTK: SQLkit http://sqlkit.argolinux.org/ Kiwihttp://www.async.com.br/projects/kiwi/ Glomhttp://www.glom.org Openoffice Base http://www.openoffice.org/product/base.html Libreoffice Base http://www.libreoffice.org/features/base/ OpenERP http://www.openerp.org Tryton http://www.tryton.org Dabo (they're about to release 1.0 for Pycon), Pypapi, Camelot, SQLkit seem to be the most actively developed and best documented ones. OpenERP and Tryton are ERP systems that can also be used as frameworks for non-ERP custom applications. Apparently defunct: Pythoncard http://pythoncard.sourceforge.net/ Boa Constructor http://boa-constructor.sourceforge.net/ Knoda http://www.knoda.org/ Rekall ? Gemello http://abu.sourceforge.net/ Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQT app accessible over network?
> As far as doing client/server stuff with just a database engine, > unless you have tight control over the environment end to end, from a > security pov, it's not a good idea to expose the database engine > itself to the internet. Better to put a restricted web services API > in front of it that handles all the authorization needs > (access-control) on the detailed level that you require. Excuse me but that's bullshit. PostgreSQL is definitely more secure than any self-made RPC protocol with a self-made "web" server on top of SQLite that re-invents what PostgreSQL provides "out of the box" and much more efficient that http could ever do it. Experience with security of PostgreSQL servers exposed to "the internet" has been capitalised for much more than a decade now. You won't get anywhere close to that level of security (and reliability) with your private selfmade webnonsense anytime soon. And if there's anything that all those scriptkiddies know their way with it's http servers. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQT app accessible over network?
> My concern is that using postgres or mysql for this would be akin to > using a sledgehammer to swat a fly, I wouldn't use MySQL for anything that requires anything else than "select". And PostgreSQL has extremely spartanic resource requirements in the default configuration. It runs on Linux on hardware where (the most recent) Windows alone wouldn't run. > My other reason for wanting one 'central' app is that there are > various functions (setting up the tournament, closing registration, > editing scores, finalizing results) that I really *don't* want the > satellite/client apps to be able to do. Easy, you simply restrict access rights to the corresponding tables for the individual users. Any halfway decent database application framework will allow to configure the application correspondingly for each user. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQT app accessible over network?
> I've been working at learning python off and on now for a while, with > a couple programs in mind as a goal - kind of specialized stuff that > I can't seem to find a good match for already available, competitor > records, score-keeping & results for an amateur sports tournament. So you want to develop a database application. That's a standard case. > Probably 98-99% of the time the match administration would be done by > a single individual on a single PC, which seems like it would be > nearly ideal for a desktop application implemented in PyQt4 or > similar. The problem is (as usual) those edge cases where there are > enough volunteers/resources to have more than one person doing data > entry (maybe 2-3 in practice, but lets say 10-12 for arguments sake > to pad things a bit). PostgreSQL and the frameworks mentioned below don't care for the number of clients. You could buy a zSeries (or whatever they are called now) from IBM and serve thousands of clients simultaneously if you needed to. > What I was wondering is what would be a good way of handling this > with a PyQt app? Build the desktop app first, and add some sort of > functionality to enable a lightweight web server and framework for > the additional data entry 'clients'? No, you just implement a GUI in whatever GUI framework you want (PyQt, PyGTK, wxPython) and use a client-server RDBMS for storage. No web-nonsense gadgetry required with bloated cursor-animation "browsers" etc.. For the storage I recommend PostgreSQL, for the client GUI, there are several frameworks available: using PyQt (& Sqlalchemy): Pypapi: www.pypapi.org Camelot: www.python-camelot.com Qtalchemy: www.qtalchemy.org using PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi Glom: www.glom.org using wxPython: Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Pypapi, Camelot, Sqlkit and Dabo seem to be the most active and best documented/supported ones. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Maximum Likelihood Estimation
> I am looking for a Python implementation of Maximum Likelihood > Estimation. If any one can kindly suggest. With a google search it > seems scipy,numpy,statsmodels have modules, but as I am not finding > proper example workouts I am failing to use them. For statistics I would suggest using R (http://www.r-project.org/) through RPy (http://rpy.sourceforge.net/). Both have dedicated mailinglists as well as extensive documentation. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: The best, friendly and easy use Python Editor.
> for all senior can you suggest me the best, friendly and easy use > with nice GUI editor for me, and have many a good features such as > auto complete/auto correct. Depends on what you are used to. If you're used to bare-bones editors such as emacs, vim etc, they can be used for Python. If you're used to IDEs, WingIDE is one long-standing competitor. The "101" version is free. There are also editors implemented *in* Python, which can be used for programming Python, such as Editra, which features quite a few useful plugins. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Migrate from Access 2010 / VBA
> The reporting question is the one that gives me the greatest concern > when I think about switching to Python. Not Python, but FOSS, cross-platform and it works with PostgreSQL: http://www.xtuple.com/openrpt Apart from that one, among the mentioned DB RAD frameworks, at least Dabo and Camelot include report builders. And, again; Libreoffice Base comes with a reporting framework, although the latest version afaik has a currently unresolved bug, so you'll have to retrograde to an older version if you want to use it. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Migrate from Access 2010 / VBA
> One program that claims to be working towards Access replacement is > Kexi. It's not written in Python, but I think it does use Python as a > scripting language, just as Access uses VBA. I doubt it's anywhere > near Access yet, but it's worth a look: > > http://kexi-project.org/about.html Unfortunately, Kexi doesn't support composite keys yet, so it's essentially useless for real-world databases so far. :-( Rekall appears to be dead and so does Knoda. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Migrate from Access 2010 / VBA
> I am the lone developer of db apps at a company of 350+ employees. > Everything is done in MS Access 2010 and VBA. I'm frustrated with the > limitations of this platform and have been considering switching to > Python. > > I've been experimenting with the language for a year or so, > and feel comfortable with the basics. > > I am concerned that I'll have a hard time replacing the access form > and report designers. I've worked a little with TKinter, but it's a > far cry from the GUI designer in Access. The list of Python frameworks for rapid development of desktop (i.e. non-Web) database applications currently contains: using PyQt (& Sqlalchemy): Pypapi: www.pypapi.org Camelot: www.python-camelot.com Qtalchemy: www.qtalchemy.org using PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi using wxPython: Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Pypapi, Camelot, Sqlkit and Dabo seem to be the most active and best documented/supported ones. > Finding a professional grade report designer looks like an even > bigger challenge. LibreOffice is imho quite useful for database reporting. It comes with a native (SDBC) driver for PostgreSQL and allows Python scripting. LibreOffice Base can even be useful for CRUD GUIs. > I don't need to port any applications, but I will need to use the > data (mdb/accede format), Don't. Put your data into an *actually* transaction-safe RDBMS (which "Jet" is *not*), such as e.g. PostgreSQL. > design a variety of reports with multi-level groupings, and deliver > them to many individual recipients via email. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Can somebody give me an advice about what to learn?
> >> The point why Ruby was started (perceived deficit of > >> object-orientation) has been remedied since Python 2.2. > > > > Not completely. At the least, there's arguably still the issue of > > len() and friends (vs. `.length` etc.), and also of `self` being > > explicit. > > I'm not entirely sure which "perceived deficit of object-orientation" > is being talked about, or why anyone but OOP purists would consider > that a problem. Yukihiro Matsumoto did. I myself never perceived any lack of object-orientation with Python, since I've learned programming with Pascal anyway. >;-> I just wanted to point out that given the state of Python today, no one would probably consider starting Ruby any more. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Can somebody give me an advice about what to learn?
> I'm really new to Usenet/Newsgroups, but... I'd like to learn some > new programming language, because I learnt a bit of Perl though its > OOP is ugly. So, after searching a bit, I found Python and Ruby, and > both of they are cute. So, assuming you'll say me "learn python", why > should I learn it over Ruby? The point why Ruby was started (perceived deficit of object-orientation) has been remedied since Python 2.2. However, Ruby has reproduced quite a few of those well-known problems of other languages that Python deliberately avoids (such as e.g. deficit of orthogonality) and that make reading and understanding code difficult, besides introducing sources for potential bugs. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: simple client data base
> Personally, I wouldn't bother with SQLAlchemy for this. I'd just use > Python as the front end, PostgreSQL for the database, and psycopg2 > for the interface. Then you have to implement the entire logic, "event binding" etc. yourself. If you use e.g. Pypapi (the latest version), implementing an entire CRUD application is as simple as declaring your domain object model and laying out your GUI with Qt Designer. In Sqlkit, you don't have to do much more, you just don't use a designer for the GUI, but also a declarative approach. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: simple client data base
> Hello all, I am learning to program in python. I have a need to make a > program that can store, retrieve, add, and delete client data such as > name, address, social, telephone number and similar information. This > would be a small client database for my wife who has a home accounting > business. Python imho would be in need of a really good accounting application as a "demonstrator" for its capabilities. ;-) > I have been reading about lists, tuples, and dictionary data > structures in python and I am confused as to which would be more > appropriate for a simple database. > > I know that python has real database capabilities but I'm not there > yet and would like to proceed with as simple a structure as possible. The list of Python frameworks for rapid development of desktop (i.e. non-Web) database applications currently contains: using PyQt (& Sqlalchemy): Pypapi: www.pypapi.org Camelot: www.python-camelot.com Qtalchemy: www.qtalchemy.org using PyGTK: Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy) Kiwi: www.async.com.br/projects/kiwi using wxPython: Dabo: www.dabodev.com Defis: sourceforge.net/projects/defis (Russian only) GNUe: www.gnuenterprise.org Pypapi, Camelot, Sqlkit and Dabo seem to be the most active and best documented/supported ones. Sqlalchemy (www.sqlalchemy.org) seems to be "quite useful" for working with databases. Those of the above mentioned frameworks that don't use it do so for historic reasons, because the corresponding project started before Sqlalchemy became known. If you want to rely on not losing your data, you might want to use PostgreSQL (www.postgresql.org) as a storage backend with any of these. Sincerely, Wolfgang P.S.: If anyone knows of frameworks not listed here, thanks for mailing me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for an IPC solution
> There are just so many IPC modules out there. I'm looking for a > solution for developing a new a multi-tier application. The core > application will be running on a single computer, so the IPC should > be using shared memory (or mmap) and have very short response times. Probably the fastest I/RPC implementation for Python should be OmniOrbpy: http://omniorb.sourceforge.net/ It's cross-platform, language-independent and standard-(Corba-) compliant. > I have seen a stand alone cross platform IPC server before that could > serve "channels", and send/receive messages using these channels. But > I don't remember its name and now I cannot find it. Can somebody > please help? If it's just for "messaging", Spread should be interesting: http://www.spread.org/ Also cross-platform & language-independent. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: The way to develope a graphical application to manage a Postgres database
> Can one advices me where to go? There are a number of Python frameworks for GUI database applications: - Dabo (wxPython) - Sqlkit (PyGTK & SQLalchemy) - Pypapi (PyQt & SQLalchemy) - Camelot (PyQt & SQLalchemy) - Qtalchemy (PyQt & SQLalchemy) - Openobject (PyGTK) - Defis (wxPython & SQLalchemy), Russian only - Kiwi (PyGTK) Not sure whether these are still active: - Gnuenterprise (wxPython) - Pythoncard (wxPython) Sincerely, Wolfgang Keller -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> >> No matter how cool it may seem to create simple GUIs manually or to > >> write business letters using LaTeX: just try to persuade people to > >> move from Word to LaTeX for business letters... > > > > Good example. > > > > I have done nearly exactly this* - but it was only possible thanks > > to LyX. > > > *I moved not from Wugh, but from other software to LyX/LaTeX for > > all my document processing. > But of course, you were only doing so because you had LyX available, > which is the equivalent of an easy-to-use GUI builder. No need to argue here. This was exactly my point. :-) > So maybe I should be more precise: just try to persuade people to move > from Word to *pure* LaTeX for business letters... Nearly impossible. And this was exactly my point. Again, no need to argue here. :-) The success of LyX (and TeXmacs and BaKoMaTeX and Scientific Word...) proves imho that the LaTeX community had missed to offer a "syntax-hiding"-GUI with LaTeX some 20 years ago. And the lack of success of Python so far to replace, in your application case, Labview, or, in my application case, all those proprietary 4GL IDEs/frameworks/GUI builders (just check the success that Realbasic has) proves imho that the Python community has totally missed to address the vast crowd of potential users who are domain experts in other domains than software development. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
On Thu, 14 Jun 2012 12:59:23 -0700 (PDT) CM wrote: > On Jun 14, 2:25Â pm, Wolfgang Keller wrote: > > > > What is needed for domain specialists are frameworks and related > > tools such as GUI builders that allow them to write exclusively the > > domain-specific code (this is where a domain specialist will always > > be better than any software developer), layout the GUI as > > ergonomically convenient (same) and then have the framework do all > > the rest. > > Above this you also mentioned a disdain for the need for "glue code", > which in the context of your post seemed to be binding to event > handlers. With "glue code" I mean any code other than that which serves to implement purely domain-specific behaviour. > So is there a possible way for a GUI builder to *automatically* bind > widgets to the appropriate functions in your domain-specific code? > It's hard to see how this would be generally possible, even with an > AI (maybe a mind-reading AI would work). > > Or maybe I'm misunderstanding something. Probably, since there are GUI builders/frameworks available that do what I described. I have already pointed to some for my specific type of application (database applications) that don't even need any GUI definition at all, since the GUI is entirely reflected from the domain model. Which I would not consider as the most ergonomic way to define a GUI. Unfortunately these excellent GUI builders and frameworks all use languages which imho are not at all suitable for domain specialists who are not full-time software developers by training. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
Danger: Flame ahead! > I think efforts to make a better, and more definitive, "GUI builder" > for Python should focus on makigng an easy to use "IDE" for creating > these kinds of Python-HTMl-Javascript front ends for applications. The idea of so-called "web applications" is a cerebral flatulance emanating from braindead morons (typically the pointy-haired type), sorry. >From the perspective of the domain specialist who needs to get some work done and who needs to get it done efficiently they are simply unusable. The "functionality" that such "web interfaces" provide is ridiculously poor, they are clumsy to use and even worse hourglass-display systems than the junk that MS or SAP sell. Besides the fact that they require obscene amounts of runtime ressources. Besides... Sorry, this subject isn't worth wasting my brain bandwidth on it. I have started to use computers with GEM on Atari ST, MacOS 6.0.7 and DOS 3.3, and if all those "web mailers" or "Google apps" had been the only applications available back then I would have never started to use computers at all. In short: "web applications" are in no way a solution to the mentioned problem, but they make this problem worse by piling up other problems on top of it. End of flame. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> object mainwindow=GTK2.Window(GTK2.WindowToplevel);
> mainwindow->set_title("Timing")->set_default_size
> (400,300)->signal_connect("destroy",window_destroy); GTK2.HbuttonBox
> btns=GTK2.HbuttonBox()->set_layout(GTK2.BUTTONBOX_SPREAD); foreach
> (labels,string lbl) btns->add(buttons[lbl]=button(lbl,mode_change));
> mainwindow->add(GTK2.Vbox(0,0)
>
> ->add(GTK2.TextView(buffer=GTK2.TextBuffer())->set_size_request(0,0))
> ->pack_start(btns,0,0,0))->show_all();
>
> If you're a complete non-programmer, then of course that's an opaque
> block of text.
Thanks for that hideously appalling example of a ridiculously low-level
mess.
If you're an occasional Python scripting dilettant, this looks like a
heap of syntax garbage of exactly that kind that has made me avoid all
C-derived languages at university (I'm a mechanical engineer) and that
makes me avoid GUI programming with Python so far.
If a domain specialist needs an application with a GUI, (s)he
typically only wants to have to tell the framework three things:
1. What the domain model looks like (classes, attributes) and what it
does in terms of behaviour (domain logic, methods). In my use-cases this
would be typically done with SQLalchemy.
2. What the GUI shows of the domain model and how it does it - define
menus with entries, layout forms/dialog boxes with fields etc. This
should be done without having to permanently look up all the specific
details of the API of the GUI framework.
3. What attribute/method of the domain model a GUI element is
"connected to" (sorry for the quotes again). This should be possible in
an interactive way, so that you can test whether GUI and code work
together as required while defining the connections.
Anything else should be done by the framework without the necessity to
write a single line of code for the "straight forward" use cases:
- creating, retrieving, updating, deleting instances of domain model
classes
- setting values of attributes instances of domain model classes
- calling methods of instances of domain model classes
Sincerely,
Wolfgang
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> > None of these were such that I could propagate it as GUI development > > tool for non-programmers / casual users. > > Sure, some are good for designing the GUI, but at the point where > > the user code is to be added, most people would be lost. > > There was a time when that was a highly advertisable feature - "build > XYZ applications without writing a single line of code!". That's the typical nonsense cheaptalk of sales promotion advertising, directed at clueless managers. What is needed for domain specialists are frameworks and related tools such as GUI builders that allow them to write exclusively the domain-specific code (this is where a domain specialist will always be better than any software developer), layout the GUI as ergonomically convenient (same) and then have the framework do all the rest. > I've seen it in database front-end builders as well as GUI tools, > same thing. But those sorts of tools tend not to be what experts want > to use. If by "experts" you mean "domain specialists", you're wrong. If you mean full-time software developers, I don't care for what they want, because they already have what they want. And where they don't have it already, they can do it themselves. > You end up having to un-learn the "easy way" before you learn the > "hard way" that lets you do everything. I see no technical reason why a GUI builder would prevent anyone to add customised code by hand. No tool/framework can cover 100%, no doubt. My point is that there are currently no frameworks/tools available for Python that cover the 90/95/98% of use cases where they would help a L-O-T. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> No matter how cool it may seem to create simple GUIs manually or to > write business letters using LaTeX: just try to persuade people to > move from Word to LaTeX for business letters... Good example. I have done nearly exactly this* - but it was only possible thanks to LyX. Sincerely, Wolfgang *I moved not from Wugh, but from other software to LyX/LaTeX for all my document processing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> > Tkinter is imho honestly the very best "argument" if you want to > > make potential new users turn their backs away from Python for > > good. Just show them one GUI implemented with it and, hey, wait, > > where are you running to... > > Yes, Tkinter GUI's are very ugly. > > http://www.codebykevin.com/phynchronicity-running.png > > http://www.codebykevin.com/quickwho-main.png OK, so after what - one and a half decades? - Tkinter now finally has caught up with wxPython and PyQt (concerning the look). Which can be used in an as interactive way from the commandline interpreter as Tkinter. Argument against Tkinter withdrawn from my side. But there's afaik still no interactive GUI builder out there for any of these frameworks, nor a higher level framework that requires less glue code between bare naked "event handling" and the domain-specific code. "Event handling" - that term already raises my hair because it stinks like bulkloads of clumsy, error-prone diligence work that has nothing to do with the problem I need to get solved. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> > * Domain experts in fact who would need to implement loads of > > software to help them get their work done but can't. And since > > there's no budget for external developers, nothing get's ever done > > about this. > Well, typically or at least very often sooner or later something > gets done about this as someone finds out that all could be solved > using MS Excel and some macros / VBA programming. MS Excel is unusable for any kind of serious work, due its serious design deficiences. But that's off-topic here. VB(A) is unusable for everyday office automation because it doesn't offer an interactive commandline interpreter. Besides, both only run^H^H^Hlimp on a pathologic non-operating system that's just as unsuitable for any productive work. But that's off-topic, too. > I would prefer people to invest the same time into a Python based > solution. > But then we're back to the initial point: As long as there's no GUI > builder for Python, most people will stick to Excel / VBA / VB. There are quite a few GUI builders out there for Python. The point is that they are not very "pythonic" imho, i.e. they don't really show what the advantage of Python is for GUIs over those other languages. And imho these GUI builders, just like the frameworks that they generate code for are not very suitable for someone who's not a software developer by profession. Because they require way too much "glue code". And unfortunately the origin of this problem seems to be the open-source development model itself: Since developers of open source development tools (GUI frameworks, GUI builders etc.) usually implement these for their own use, and since these people are typically software developers by profession who come from a C++-dominated background, they don't see the necessity and they don't have any motivation to implement anything that would help all those potential Python users out there who just can't devote the time and effort required to get over that pretty huge step in the learning curve of those frameworks and tools. Please note that this is not meant as criticism to open-source developers, but as a hint that there might be a business opportunity for someone here to develop and sell something for money. ;-) Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> > What "GUI designer" would come the closest to the way that Cocoa's > > Interface Builder works? I.e. is there any one (cross-platform) that > > allows to actually "connect" the GUI created directly to the code > > and make it available "live" in an IDE? > > If you're developing on the Mac, PyObjC allows you to use Interface > Builder for developing Python apps. I know that. And no, I haven't used Interface Builder yet myself, just because I would need those GUIs also to run elsewhere than on my private Mac. > However, there are those of us who are deeply uncomfortable with IB > and related tools, such as RealBasic and LiveCode/Runtime Revolution. I haven't used any of these either, just because I don't like those languages. Their syntax is ugly, static type declarations are imho perfectly redundant for interpreted languages and besides they don't offer me an interactive interpreter, which is an absolute must-have for my day-to-day use of Python - "office automation", ad-hoc "information logistics" etc. (errr, sorry for those quotation marks again... ;-). > These tools make code organization very hard by reducing the amount > of code written to the point of the UI working by "magic," Any modern GUI framework has quite a lot of "magic" going on "behind the curtains" without that the user needs to know or understand how it works. And this is the way it _should_ be. As long as it is well documented how to use that "magic". The current GUI frameworks which are available for Python require way too much "glue code" that needs to be written by hand, imho simply because they are primitive wrappers around frameworks for C++ developers who are used to such bulkloads of slave labour. Python as a language is way ahead of C++, Java, C# etc. in terms of functionality that you can implement per coding effort required , but it simply lacks GUI frameworks and corresponding development tools that are equally efficient. > and/or by breaking up your code into little snippets that you can > only view by clicking on the widget in the UI tool. I remember reading about RAD IDEs/frameworks out there that managed to integrate/seperate their generated code with/from user-written code quite well. And which could even use external revision control systems etc.. Back in the good old days of software diversity, before MS/Java took over the whole world... > A related issue is that using a tool such as this makes you heavily > dependent on that particular tool, and subject to its developers' > priorities, release schedule, and bugs. This is true with _any_ language, library, framework or software. Heck, it's even true with hardware! If this was such a show-stopper, we would still write computer programs like this: 0100011100101010101 Well, certainly not me, in that case. > The pace of Xcode development--with Apple making frequent changes to > project formats in a backwards-incompatible way--is an example of > this. Wxwidgets/python has a reputation for frequent incompatible API changes, too... And Apple's "product politics", oh, well, errr, uhm, don't get me into that... *sigh*. If only all those third-party applications for MacOS X were available on Linux, I would happily forget about Apple's very existence. > One reason I prefer to code UI's by hand is because a) in Tkinter > it's very easy to do, Tkinter is imho honestly the very best "argument" if you want to make potential new users turn their backs away from Python for good. Just show them one GUI implemented with it and, hey, wait, where are you running to... > I think these issues are a reason that the slick "drag-and-drop" UI > builders tend to be developed by commercial software shops to support > their language and/or IDE, but find little traction among open-source > developers and languages. The point is that loads of potential "developers"(*) simply don't ever get to use Python due to the very lack of such tools (and corresponding frameworks). * Domain experts in fact who would need to implement loads of software to help them get their work done but can't. And since there's no budget for external developers, nothing get's ever done about this. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> > What "GUI designer" would come the closest to the way that Cocoa's > > Interface Builder works? I.e. is there any one (cross-platform) that > > allows to actually "connect" the GUI created directly to the code > > and make it available "live" in an IDE? > > > > This whole cycle of "design GUI"->"generate code"->add own code to > > generated code"->"run application with GUI" has always seemed very > > un-pythonic to me. A dynamic, interpreted language should allow to > > work in a more "lively", "direct" way to build a GUI. > > I'm curious about your point but I don't really understand it. Could > you try again without using any scare-quoted words? myidea.explanation.retry() Python has this insanely great thing that e.g. Delphi, Java, C#, Visual Basic, etc. lack and that's called an interactive commandline interpreter, which allows you to build GUIs while exploring/trying out the API of a GUI framework step by step. You simply type the code for the GUI at the python prompt and your GUI comes directly to life. Here's an example by someone else: http://pysnippet.blogspot.de/2010/11/getting-interactive-with-pyqt.html Now "just" (sorry for those quotes again) imagine a GUI builder that generates _and_ _runs_ the code (pyqt, wxpython, pygtk, whatever) for the GUI you edit _while_ you do so. And now imagine that this GUI builder would be integrated with the IDE you use (I use one), so that the GUI code is run in the same interpreter instance as the other code of your application. So that you can directly interact with your application through the GUI you build while you do so. The advantage of using a GUI builder over typing the code into the interpreter window would be that users who rarely implement a GUI(*) would not need to re-dig into the details of the API every time. This is especially tedious since those APIs are essentially C++ APIs wrapped in Python and thus they are honestly simply §$%&@# to use for a certain type of Python user(*). And the lack of Python-specific documentation, tutorials etc. doesn't really help. Did I mention yet that just having to read C++ example code in documentation makes me spill my last meal over keyboard, screen etc.? Of course there's PyGUI, but that's unfortunately far from being as complete as PyQt or wxPython and unless someone creates something like an equivalent of Apache Software Foundation for Python, declares PyGUI as the canonical Python GUI framework and funds the work needed to complete it... And then you still need a GUI builder for it. *sigh* > Maybe given an example of creating a small text editor application > with a GUI builder/ IDE in this Pythonic way you are hoping for. I'm not into text editors as example applications since I don't develop text editors, I rarely even use one. And besides, I don't think any typical user(*) of such a GUI builder would ever implement a text editor in his whole life. Personally, my typical use of such a GUI builder would be for database applications. Which make up, according to my experience, for at least 90% of all custom-built applications in companies. Today, these applications have to be made by external, paid developers who have typically no clue of the application domain in question. Consequently, the applications, no matter how many pages of detailed specifications you as the domain expert write, never do what you wanted them to do. Although just writing the specification takes more time than it would take to implement it myself if only the (GUI) tools and (GUI) frameworks(**) for Python would be at the level required to make them useful for such "developers" as me(*). And did I mention that the cost of external developers (plus the overhead cost for interaction with them) makes them prohibitive anyway? And did I mention that the time required such external development (plus the overhead time for interaction with the external developers) takes doesn't help either? * Such as "casual" Python scripting dilettants who are not full-time software developers but domain experts who just use Python to help get their main work done. ** In my case of database applications, something like this: http://www.nakedobjects.org/book/ http://www.nakedobjects.org/downloads/Pawson%20thesis.pdf Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
> I want a gui designer that writes the gui code for me. I don't want to > write gui code. what is the gui designer that is most popular? > I tried boa-constructor, and it works, but I am concerned about how > dated it seems to be with no updates in over six years. Sorry to "hijack" your thread, but since this is a very related question... What "GUI designer" would come the closest to the way that Cocoa's Interface Builder works? I.e. is there any one (cross-platform) that allows to actually "connect" the GUI created directly to the code and make it available "live" in an IDE? This whole cycle of "design GUI"->"generate code"->add own code to generated code"->"run application with GUI" has always seemed very un-pythonic to me. A dynamic, interpreted language should allow to work in a more "lively", "direct" way to build a GUI. TIA, Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Software tool for stochastic simulation as well as for the stochastic optimization
> I plan to work in decision support field in environmental engineering > so I will use both the stochastic simulation as well as the stochastic > optimization. > I would like to select the best for both approaches software tool. > > what you suggest ... Matlab ... python ... something else? I have no clue whether it does stochastic simulation and optimisation, but R is THE free open-source statistic analysis tool. It does have a Python interface, RPy. And there's a free open-source replacement for Matlab, Scilab. Which has a Python interface as well. Sincerely, Wolfgang -- HOMO HOMINI HOSTISIN FELIBUS FELICITAS -- http://mail.python.org/mailman/listinfo/python-list
Re: open office in another language?
> I'm a somewhat-satisfied openoffice.org user. I mean it works, but if > it weren't in Java I'd be doing some of my own tweaking. But since > it's in Java I stay away... no likey. OpenOffice (now LibreOffice, btw.) is not implemented in Java, if that's what you mean. It _is_ scriptable in Python, however there doesn't seem to be any documentation available. Ask on the Libreoffice-users list. > Has there been any talk of doing another similar office suite, or > maybe just writer + spreadsheet, in a better language eg python? You wouldn't implement "Office"-style software entirely in Python. Other FOSS "Office"-style software apart from LibreOffice is, e.g. Abiword and GNUmeric. Both are scriptable in Python as well, iirc. And, of course, there's LyX (also scriptable in Python), which I do prefer a L-O-T over "word processor" applications for writing. And there is Pyspread. Sincerely, Wolfgang -- HOMO HOMINI HOSTISIN FELIBUS FELICITAS -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyGUI 2.5
> Lots of new stuff in this version. Highlights include: >- GridView - a user-defined view consisting of a regular grid of > cells. > >- PaletteView - a GridView specialised for implementing tool > palettes. Any chance to see a hierarchical multi-column TreeListView anytime soon? Sincerely, Wolfgang -- Führungskräfte leisten keine Arbeit(D'Alembert) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
> > Are there any other, better solutions? > > Others are e.g.: > - Pypapi > - Camelot > - Kiwi > - Sqlkit > - Gnuenterprise And I've just learned of another one: - QtAlchemy Sincerely, Wolfgang -- Führungskräfte leisten keine Arbeit(D'Alembert) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Card alternatives?
> Are there any other, better solutions? Others are e.g.: - Pypapi - Camelot - Kiwi - Sqlkit - Gnuenterprise etc... Sincerely, Wolfgang -- Führungskräfte leisten keine Arbeit(D'Alembert) -- http://mail.python.org/mailman/listinfo/python-list
Re: Make Python "portable" by default! (Re: Python IDE/text-editor)
> >> You can't run Python programs without a Python interpreter > >> installed. > > > > Wrong. > > > > See e.g. http://www.portablepython.com/ > > Uhm... how does that disprove? Which part of the word "installed" don't you understand while actually using it? >;-> > Whatever language you distributed code > is in, you need something on the computer that can read it. The point is that you don't need to _install_ it. If the developer has a brain. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Make Python "portable" by default! (Re: Python IDE/text-editor)
> You can't run Python programs without a Python interpreter installed.
Wrong.
See e.g. http://www.portablepython.com/
BTW: Imho, the Python interpreter should be made
"portable" ("zero-install") _by default_. "Installing" it should be
purely optional.
Sincerely,
Wolfgang Keller
--
http://mail.python.org/mailman/listinfo/python-list
Generating diagrams from PostgreSQL with Python (Re: postgresql_autodoc in Python?)
Hello, I will re-precise my question: Has anyone ever implemented a script in Python that generates documentation (especially diagrams, in a format such as e.g. Dia, Inkscape SVG or Tikz) for a PostgreSQL database either from an SQL script or by connecting to the database? Postgresql_autodoc is unfortunately written in Perl. >;-> TIA, And, btw., please respect my .sig, Sincerely, Wolfgang Keller -- NO "Courtesy Copies" PLEASE! -- http://mail.python.org/mailman/listinfo/python-list
postgresql_autodoc in Python?
Hello, has anyone ever implemented something similar to postgresql_autodoc in Python? TIA, Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for professsional Windows GUI apps?
> I need controls for business apps like access to databases, good data > grid, printing reports (with or without barcodes), etc. The area of _desktop_ database application development indeed looks like a vast and very hostile desert in the Python landscape. The only framework that seems to be worth trying is Dabo. Unfortunately there's little documentation, and that's mostly outdated. There's also Kiwi, but that's even less well documented. And GNU Enterprise essentially seems to be dead. Sincerely, Wolfgang -- NO "Courtesy Copies" PLEASE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python package Management GUI - New Project on Sourceforge
> David, I would really recommend that you > seriously consider using the Tcp/Tk toolkit. I would seriously disrecommend using Tcl/Tk. > Why ? Because it doesn't allow to build a GUI application with not-ridiculous functionality, "look-and-feel" and quirk-free behaviour. > Because of my point above, you'll find the tool will most likely have > a greater impact and uptake than one requiring a user or developer to > install a 3rd party toolkit and library just to use your gui package > manager :) I'm using applications that use wxPython, PyGTK, PyQt etc. every day that don't require to "install" anything, not even _themselves_. In fact this (zero-install applications) is the _only_ actually "simple" way to distribute applications. And it is the standard way to distribute applications for the Mac. -- http://mail.python.org/mailman/listinfo/python-list
Re: New to python, open source Mac OS X IDE?
> I'm on a Mac. I use Netbeans for Java, PHP, and C if needed. Do you > even use an IDE for Python? WingIDE Not open source, but by far the best that I've tried. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Re: Does omniORBpy 3.2 supports DII?
> My apologies if this is not the correct forum for thses quiestions, It's not the wrong place to ask, but you're more likely to get answers from the omniORB mailing lists: http://www.omniorb-support.com/mailman/listinfo Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Modeling (Re: Pythonic ORM with support for composite primary/foreign keys?)
Hello, thanks for the hints towards Elixir and Storm. In fact I would have loved to use Modeling (http://modeling.sourceforge.net/), as it seems to fulfil all my requirements perfectly so far, except the one with the composite keys. In particular I like its proximity to EOF (R.I.P.) concerning the basic concepts and the notification service. I would like the notification service even more if it was possible to send notifications directly from PostgreSQL. ;-) Well, maybe that would even be possible using PL/Python... :-? Modeling imho is especially well documented and at a first glance the sourcecode seems to be quite comprehensible even to me (unlike SQLAlchemy :-( ). The author has stated that composite keys were foreseen to be implemented and that the code was already written considering this feature. So I'll maybe even try to "hack" it until it works for my schema, with (hopefully) some spoonfeeding by the original author. But in case my skills aren't enough to actually make it work, I need a fallback option. Maybe someone could even convince someone else >;-> to implement a "plug-in" for Gaphor (or for MetaEdit) for Modeling, so that one could generate (and round-trip) nice "colorful and children-suitable" diagrams for the CXOs... >:-> TIA, Sincerely, Wolfgang Keller -- http://mail.python.org/mailman/listinfo/python-list
