pyjamas-desktop running under python 2.6... on wine (!)
i think this is so hilarious and just such a stunning achievement by the wine team that i had to share it with people. the writeup's here: http://appdb.winehq.org/objectManager.php?sClass=version&iId=25765 but, to summarise: * python2.6 runs under wine (the win32 emulator) * so does python-comtypes (0.6.1) * you can also install IE6, 7 or 8 under wine * then you can also install pyjamas * and at the C:\ DOS prompt you can run "python.exe Hello.py" ... and it will work! you'll actually get a desktop application as a win32 GDI program running on your X-Windows GNU/Linux desktop :) i just fell off my chair when that happened. underneath, what's happening is that pyjd's mshtml.py is firing up a COM interface to MSHTML.DLL (which is part of IE), it's embedding an IWebBrowser2 OCX control into a w32 GDI window (using a ctypes wrapper to do that, if you're interested in those kinds of details), and then handing that over to pyjamas. and this is all emulated! it's just an absolutely staggering testament to how far wine has come that it can run python.exe in the first place, but being able to run COM interfaces around something as sophisticated as MSHTML.DLL is just mind-blowing. all right, rant over :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Framework for a beginner
On Thu, Apr 19, 2012 at 1:21 PM, Alek Storm wrote:
> On Thu, Apr 19, 2012 at 7:12 AM, lkcl luke wrote:
>>
>> On Thu, Apr 19, 2012 at 12:20 PM, Alek Storm wrote:
>> > Why not use list comprehension syntax?
>>
>> because it's less characters to type, and thus less characters to
>> read. i find that syntax incredibly klunky. left to right you're
>> reading, "you declare something to be the case... and then oh whoops
>> actually it's not really the case because it's modified by a list
>> thing" - it breaks reading expectations.
>>
>> that's what i meant about beauty and elegance. the "bang per buck"
>> ratio in python, results obtained for the number of characters used,
>> is higher, and that's something that i personally find to be a
>> priority over speed.
>
>
> Did I miss something? `[a+1 for a in some_list]` is shorter than both
> `map(lambda a: a+1, some_list)` and `some_list.map(lambda a: a+1)`.
:)
yes you missed something. :)
a) if you use that lambda a:a+1 a lot, you make it an actual
function, don't you? even for clarity you'd still probably use a
function not a lambda. i use map quite a lot, filter and reduce not
so much. a more real-world example was one that i actually gave
initially: map(str, l). or, the syntax i really prefer which doesn't
exist: l.map(str). or, one that i also use in web applications or
their back-ends: map(int, l). if you have a comma-separated set of
variables in a single string, like this: "5, 20, 3", i tend to use
this:
from string import strip
l = map(int, map(strip, l.split(",")))
ok to make it clearer i sometimes do that on 3 separate lines.
i'd _love_ it to be this:
l = l.split(",").map(strip).map(int)
or even better would be this:
l = l.split(",").map(strip, int)
b) read the text from left to right, in plain english:
* map(str, l): you're going to map i.e. apply a string function to a
list's members.
(now you see why i keep getting confused with "map", because the
natural language version of this is "map a list's members to a string"
- the other way round)
* a+1 for a in l: take an expression which is a mathematical
operation and therefore has the expectation that its arguments are
mathematical in nature. then oh damn it wait a minute, actually
there's more going on here: for every variable in a list, use the
variables in the expression to make a new list...
i'm belabouring the point (not entirely intentionally) but you see how
clumsy that is? it's probably just as complex in the actual
lexer/grammar file in the http://python.org source code itself, as it
is to think about in real life and to psychologically parse in
english. you actually have to think *backwards*!
is that clearer, or have i added mud? :)
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Framework for a beginner
On Thu, Apr 19, 2012 at 12:20 PM, Alek Storm wrote: > On Wed, Apr 18, 2012 at 11:21 PM, lkcl wrote: >> >> On Apr 11, 9:11 pm, biofob...@gmail.com wrote: >> >> > I am new to python and only have read the Byte of Python ebook, but want >> > to move to the web. I am tired of being a CMS tweaker and after I tried >> > python, ruby and php, the python language makes more sense (if that makes >> > any "sense" for the real programmers). >> >> yeah, it does :) python is... the best word i can describe it is: >> it's beautiful. it has an elegance of expression that is only marred >> by the rather silly mistake of not taking map, filter and reduce into >> the list object itself: l.map(str) for example would be intuitive, >> compact and elegant. instead, i have to look up how to use map each >> and every damn time! the reason for the mistake is historical: map, >> filter and reduce were contributed by a lisp programmer. that lisp >> programmer, presumably, was used to everything being function(args...) >> and it simply didn't occur to anyone to properly integrate map, filter >> and reduce properly into the list objects that they work with. > > > Why not use list comprehension syntax? because it's less characters to type, and thus less characters to read. i find that syntax incredibly klunky. left to right you're reading, "you declare something to be the case... and then oh whoops actually it's not really the case because it's modified by a list thing" - it breaks reading expectations. that's what i meant about beauty and elegance. the "bang per buck" ratio in python, results obtained for the number of characters used, is higher, and that's something that i personally find to be a priority over speed. you don't *have* to use lambdas with map and reduce, you just have to use a function, where a lambda happens to be a nameless function. another example of the compactness of python is kicking around somewhere, i wish i could remember where it is. it compares scheme with python and java. scheme does this amazing programming "thing" in a single operator, expressed in 3 characters. python manages the same thing in about 10, and java requires *six* lines! > It gets you map and filter > functionality for free, and is more readable than python's clunky version of > lambdas. I believe they're faster than the for-loop equivalents, but I'm not > sure about the actual map() and filter() functions (reduce() was removed > from 3.0 for reasons I will never understand). likewise. /salutes -- http://mail.python.org/mailman/listinfo/python-list
Re: Framework for a beginner
On Apr 11, 9:11 pm, biofob...@gmail.com wrote: > I am new to python and only have read the Byte of Python ebook, but want to > move to the web. I am tired of being a CMS tweaker and after I tried python, > ruby and php, the python language makes more sense (if that makes any "sense" > for the real programmers). yeah, it does :) python is... the best word i can describe it is: it's beautiful. it has an elegance of expression that is only marred by the rather silly mistake of not taking map, filter and reduce into the list object itself: l.map(str) for example would be intuitive, compact and elegant. instead, i have to look up how to use map each and every damn time! the reason for the mistake is historical: map, filter and reduce were contributed by a lisp programmer. that lisp programmer, presumably, was used to everything being function(args...) and it simply didn't occur to anyone to properly integrate map, filter and reduce properly into the list objects that they work with. *shrugs* :) but that's literally the only thing about python that i could possibly complain about. everything else, it's just... beautiful. i think also that as a general rule, python programmers are just... more intelligent. either it does something to their brains, or... yeah :) > I heard a lot of good things about Django, Pyramid, etc, but I dont want to > pick the most used or the one with the most magic. Instead I was thinking > about one that could "teach" me python along the way. My plan is to rebuild > my portfolio using python and a framework and also benefit my python learning > along the way. as you've seen quite a few people respond already by now, i won't extol the virtues of different web frameworks, but one thing that's very hard to assess is what you need. what exactly do you intend to do? let me give you an example. i started doing web programming with python, back in 2001. the only available big web framework was zope, and it was far too cumbersome. so i wrote my own sql table-generator (called pysqldb - you can still find it on sourceforge), and i wrote my own HTML table and form generator. i used cgi-bin. that was good enough. then i discovered ian bicking's sqlobject and sqlforms, and started using that, for a bit (it became the basis of turbogears). _then_ i discovered django, and went nuts over that. and then, i discovered pyjamas, but i *still* used django for the back-end, because of the database table capabilities, and *especially* because of django south (and then django evolution) which, in a large environment where stability and stable upgradeablity is paramount, you really _really_ should investigate. theeen, because pyjamas basically uses JSONRPC, and you only need to use HTTP POST for file uploads and HTTP GET for file downloads, i started looking at alternative _really_ minimalist frameworks, and i mean severely minimalist. mod_python (yes really *just* mod_python - not even a framework!), going back to cgi-bin with a view to doing fast_cgi in a single process, and even experimented with using yield and generators but that's getting seeeriously esoteric. more recently i've discovered mongrel2, which i love, and will play with more when i have a chance or the need. but for the latest project, i'm not even using SQL: i'm using something called kirbybase, and i'm using cgi-bin. there's simply no need for speed: i don't _want_ to install django when it's not even needed. i needed file upload: i just used CGI multi-part forms by googling for it (there's a recipe on activestate that's about 30 lines of code demo). i needed file download: i googled "cgi-bin python file download" and yet again, another recipe on activestate showed me how: it's doable in about 20 lines. i wrote a JSONRPC service - again cgi- bin based: it's 140 lines of code. that's enough - it does the job, and i don't need more! http://pyjs.org/pygit/pygit.html?repo=pyjamas.git#file=pyjs/jsonrpc/cgihandler&id=4fb8b7d7902ddbb79507c977eb52f6645f9912ef so the point is: if you don't need something, and you're never going to need it, don't use it. i stuck with django not because of django, but because the database migration module is just fricking awesome. but when i didn't even need SQL relational queries, i dropped the whole of django like a stone. so - really: you really do need to let us know what kinds of web sites you intend to write. are they static (unlikely), is there data involved, is there file upload/download involved, will there be lots of data input, will there be automatic file creation involved (PDF reports from database queries for example), will there be multimedia (audio, video, live or just pre-recorded) involved, etc. etc. all of these things have such a massive influence on what's best practice to use, dude :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Framework for a beginner
On Apr 17, 9:54 am, Bryan wrote: > If by rebuilding your portfolio you mean to position yourself for a > job, then popularity counts a lot. As measured by job openings, Django > is king. yeah i can attest to that. i never get the jobs, though :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Pyjamas 0.8.1~+alpha1 released
Terry randomly wrote: > > Pyjamas is slowly converting to running its own infrastructure using pyjamas > > applications (which also operate as Desktop applications). This includes: > > > > * http://pyjs.org/pygit/ - a git repository viewer using python-git > seems to work fine yaay. thanks for checking. source code viewer is here: http://pyjs.org/pygit/pygit.html?repo=pyjamasgitweb.git it should be "git clone g...@pyjs.org:pyjamasgitweb.git". hmm, i should do a separate announcement about that, shouldn't i? > > The README is available here: > > http://pyjs.org/pygit/#file=README&id=0d4b6787d01c3d90f2c8801c5c4c45e34145bbdd&mimetype=text/plain > It starts 'Current Release: 0.7' ahh, yep - i'd forgotten to do a git push :) http://pyjs.org/pygit/#file=README&id=01865ec42f5ed019812685b41821572f34f0b1a2&mimetype=text/plain typical, huh? l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - a modest proposal
On Mar 2, 6:42 am, lkcl wrote: > ah. right. you're either referring to pyjampiler (in the pyjs > world) or to > [...] > the former actually got taken to an extreme by a group who embedded > the pyjs 0.5 compiler into their application environment, i keep > forgetting > what it's called. http://nagare.org. took me a while to remember. sorry about that. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - a modest proposal
folks hi, apologies for picking this up so late - it's only when i find these things through random searches that i encounter the occasional post. At some point wa in the distant past, g4b wrote: > On the subject of the gui discussion mentioned here last year, > which you get lead to if you read around in the pyjamas docs, > I have to admit, since I know both development types (gwt, wx, qt) > and (django, jquery), I have to state the fact, that pyjamas should > also consider bonding with native javascript library developments. ah. right. you're either referring to pyjampiler (in the pyjs world) or to a vunnderbarr hidden iframe trick (in the pyjd world) where the execution results of a random javascript function has to store its results in the iframe (in JSON format) in order for the python world to monitor it, pick it up, decode it and pretend that nothing weird happened. the former actually got taken to an extreme by a group who embedded the pyjs 0.5 compiler into their application environment, i keep forgetting what it's called. but yes, they just put an "@decorator" in front of functions in the django source code, automatic recompile server-side, absolutely superb approach. > I was just looking at pyquery, a python implementation of jquery, > which could easily backbone jquery itself on the python end. you _what_??? pyquery? bizarre! you mean this? http://pypi.python.org/pypi/pyquery > Now this is not pyjamas' task, but the pyjs compiler could be used, > so that jquery code could be written for both languages. with a bit of coordination between the projects? yes, quite likely. $ however isn't a valid python variable name. but i get the point. > Long story short: if you could write jquery in python which actually > compiles into jquery in javascript, and even runs on python itself, > you could deploy widgets natively from python in django, > and dont have to leave python to improve webapplications with its native > strengths. oh i see what you mean - compiling into jquery. yes, that would take care of the $ problem. that actually wouldn't be too hard to do, either. it'd also make an extremely neat GSoC project. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Rant on web browsers
On Jun 14, 7:31 am, Chris Angelico wrote: > Random rant and not very on-topic. Feel free to hit Delete and move on. > > I've just spent a day coding in Javascript, and wishing browsers > supported Python instead (or as well). All I needed to do was take two ok your next best thing is to try pyjampiler. it's the absolute minimum and easiest stuff you'll need to be able to write code in python yet integrate it easily into a pre-existing web site. there are alternatives out there (competitor projects to pyjamas) - take a look on http://wiki.python.org/moin/WebBrowserProgramming l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Rant on web browsers
On Jun 14, 7:31 am, Chris Angelico wrote: > But if anyone feels like writing an incompatible browser, please can > you add Python scripting? http://wiki.python.org/moin/WebBrowserProgramming already been done, chris - you want the firefox plugin, pyxpcomext and then if you actually want to manipulate the DOM in the browser engine as well, you need the 2nd plugin xpcom as well. oh, i also forgot (because it's quite new) there's firebreath as well: https://github.com/Nitrogenycs/firebreath-x so... yeah, if you're completely off your head, knock yourself out :) l. p.s. pyjamas rocks! sorry, had to say that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for Web
On Jun 15, 1:11 pm, "bruno.desthuilli...@gmail.com" wrote: > On Jun 15, 9:50 am, sidRo wrote: > > > Is Python only for server side? > > Is it a theoretical question or a practical one ?-) > > More seriously: except for the old proof-of-concept Grail browser, no > known browser uses Python as a client-side scripting language. ahh paul bonser _did_ make an attempt to write a web browser in python: he got quite a long way but nobody helped him out, unfortunately. i did actually get grail browser up-and-running again, under python 2.5 and then 2.6 - it actually works, hurrah! :) the list of client-side (assuming you meant web browser client, sid) python programming environments is actually really quite long.. and some of them very very obscure :) i maintain (as i find them) a list, here: http://wiki.python.org/moin/WebBrowserProgramming the one that i have the most respect for (despite its DOM TR2 compliance only, and the obscure bug that most people will never encounter) is python-khtml. KHTML aka Konqueror's web browser is the granddaddy of webkit after the toerags from apple got their grubby mitts on it, and i do wish that KHTML got more love and attention, because it's a proper true free software *independent* web browser engine that is truly developed by a free software community, not a bunch of corporate lackies with a commercial axe to grind. there is quite a lot of mileage to be had from ironpython, because of course it translates to CLR (.NET) - as a result you have things like appcelerator (titanium). sadly you'll probably get that running under mono at some time when hell freezes over, but that's another story. the other one that's worth a laugh, ok maybe a snort, is the mozilla- funded project back in 2000 to add support to firefox for < script language="python" /> which actually damn well worked - properly - except that it resulted in a whopping 10mb plugin (because it was the entire python interpreter in a firefox plugin, that's why!) and was only available for firefox. oh, and building the dependencies on w32? jaezzus h christ on a bike was it a bitch. to give you an idea: the last people who attempted it were novell, some time around 2007. to get an accurate date, look up the release date on xulrunner 1.8. anyway - bottom line: there's a hell of a lot (including pyjamas of course, yaay!) but it's all pretty obscure esoteric stuff and you do have to be a bit off your head to consider using the various options available. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
On Jul 20, 3:34 am, Terry Reedy wrote: > On 7/19/2011 10:12 PM, sturlamolden wrote: > > > > > What is wrong with them: > > > 1. Designed for other languages, particularly C++, tcl and Java. > > > 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python > > has a standard library!) > > > 3. Unpythonic memory management: Python references to deleted C++ > > objects (PyQt). Manual dialog destruction (wxPython). Parent-child > > ownership might be smart in C++, but in Python we have a garbage > > collector. > > > 4. They might look bad (Tkinter, Swing with Jython). > > > 5. All projects to write a Python GUI toolkit die before they are > > finished. (General lack of interest, bindings for Qt or wxWidgets > > bloatware are mature, momentum for web development etc.) > > Greg Ewing's pygui project is still going and releasing new versions. > > > > > How I would prefer the GUI library to be, if based on "native" > > widgets: > > > 1. Lean and mean -- do nothing but GUI. No database API, networking > > API, threading API, etc. > > > 2. Do as much processing in Python as possible. No more native code > > (C, C++, Cython) than needed. > > > 3. Instances of extension types can clean themselves up on > > deallocation. No parent-child ownership model to mess things up. No > > manual clean-up. Python does all the reference counting we need. > > > 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is > > suitable. > > > 5. No particular GUI thread synchronization is needed -- Python has a > > GIL. > > > 6. Expose the event loop to Python. > > > 7. Preferably BSD-style license, not even LGPL. > > > 8. Written for Python in Python -- not bindings for a C++ or tcl > > toolkit. > > I think you described pygui. > > > Is it worth the hassle to start a new GUI toolkit project? > > Ask Greg what you might help with. > > > Or should modern deskop apps be written with something completely > > different, such as HTML5? > > An interesting question. I think thepyjamasproject is aimed in this > direction, weeelll... we kinda want to keep as many platforms supported as possible, so that includes IE6 canvas (VML) which surprisingly works pretty damn good, the only thing missing is being able to add text to VML canvas: everything else (including colour gradients) shockingly actually works. it's slow, but what do you expect out of IE6, duh. but yes we're finding that an increasing number of people are saying "i wrote a pyajamas app, it used direct HTML5, sod the browsers that don't properly support HTML5" and i think that's a good thing. > but the author says he will never port to Py3. (He explained > his reasons on this list when I suggested that.) :) it's not quiiite a matter of "never" - it's conditional. the conditions on which i, personally and extremely grudgingly, will get involved in a py3 port of pyjamas are when it becomes hellishly difficult for myself, personally, to maintain all of the components of pyjamas *including* the desktop ports (w32 MSHTML, gnu pythonwebkit project, xulrunner N.N) which people tend to forget exist for python 2.N. the reason for that are a) personally i don't like py3 (because it didn't include backwards-compatibility for python 2) b) the pyjs translator is self-contained, and has at absolutely no time any need for any links at runtime to in fact any python *at all* (because the pyjs version runs on a javascript engine *not* a python engine). there's no "never" in there - it's just that i'll keep reviewing the situation, and i anticipate / predict that it will begin to become difficult to compile python2 applications (such as python-comtypes) at some point in approx ooo... 5 to 7 years. maybe not - it's hard to say. anyway - if however someone else wants to collaborate and/or fund a py3 port of pyjamas, knock yourself out: just bear in mind that it's an estimated 18 man-month project. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 11:02 pm, Terry Reedy wrote: > On 5/18/2011 5:24 AM, lkcl wrote: > > There seem to be two somewhat separate requirement issues: the > interpreter binary and the language version. yes. [with the startling possibility of compiling the entire pyjs compiler into javascript and executing under e.g. spidermonkey's /usr/ bin/js turning that into just the one requirement - but that's another story] > > a) at the moment ahttp://python.org2.N interpreter is required to > > actually run the translator. if you usehttp://python.org2.5 or 2.6 > > you do not need to use the "--internal-ast" option. if you use 2.4, > > 2.7 or above, you will need to use --internal-ast because we're > > heavily reliant on the internal c-based "compile" module [without the > > --internal-ast option enabled]. > > I presume '--internal-ast' is a 'compile the interpreter' option. mmm... sort of. what it does is, in translator.py (the pyjs python- to-javascript compiler) is this: if options.internal_ast: import pyjamas.pgen.compile as compile # python version of compile module else: import compile # standard python compile module that "internal" compile module contains a complete independent grammar.txt file, and is basically lib2to3 re-ported *back* to being interoperable with, and a complete replacement for, the standard python "compile" module. including the ast module. we haven't *quite* got round to doing a "compile the interpreter" yet - it's half way there. the work that daniel kluev is doing, for his gsoc2011 project, will be a complete "compile the interpreter". by the time he's done, we'll even have "eval()" and "exec()" builtins... inside a web browser. > Since > I have never compilied Python (or anything else for perhaps 15 years), I > do not understand completely. Am I correct to guess that the PSF Windows > binaries for 2.7 were not compiled with the flag, and will not work? If > so, Windows users should, I would think, use the latest 2.6.6 binaries. ahh... i'm reading this as "requiring http://python.org c code to be compiled with different compilation flags". this isn't anything to do with compiling c-code: "pyjs the translator" is and always will be a pure vanilla python application, requiring absolutely no modifications to the python interpreter whatsoever. the --internal-ast option is an option which is passed to the pyjs application (which is a pure and vanilla python application). here's an example, shows the inter-relationships: /usr/bin/python pyjsbuild.py --internal-ast Hello.py python.exe pyjsbuild.py --internal-ast Hello.py * /usr/bin/python or python.exe - python2.N. * pyjsbuild.py - the pyjs python-to-javascript translator * --internal-ast - an option to pyjsbuild to tell it to use a version of compiler.ast which is written in pure python [and supports the 2.6 grammar] * Hello.py - the pyjamas application, written in python, being translated to javascript, for execution in a web browser. > > b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly > > been updated to 2.6. actual python syntax / features are therefore > > mostly 2.5, with someone having pointed out that "slice" has different > > return results it's hard to say exactly which is best to be picked, > > 2.5 or 2.6. nobody's needed slice until recently, so it's not an > > issue that's ever come up before. > > If I understand this, the safe thing to do is to stick with 2.5 syntax > and omit exotic 3.x features put into 2.6 for eventual porting to 3.x. yes. that would be the easiest path. however, we have a teeny problem: pyjamas desktop (pyjd). that's where you get to *really* execute the python code, exactly the same code that you munged through the pyjs compiler. in the pyjd case, what is going on is that it is *python* that has access to the features of the web browser engine (DOM functions, HTML5 etc.) and that is... ho hum, each engine is itself a massive project, and has to be a python c module (except for the MSHTML engine, which is COM). so for pyjd, we *have* to support whatever the latest easiest python 2.N is. that in turn dictates that we have to keep up-to-date with the python 2.N syntax/grammar, and, consequently, it dictates logically that the pyjs compiler, which *must* be interoperable with pyjd, must also support the latest python 2.N syntax/grammar. bummer, huh? :) fortunately, nobody on the pyjamas mailing list has really noticed that there _are_ any differences (!) between 2.5, 6 and 7 - except for daniel kluev, the gsoc2011 student, who is using pyjs with python-pyv8 to actually create a version of a python interpreter... by transl
python2+3
[changing subject, seems a good idea...] On May 19, 2:13 am, Terry Reedy wrote: > On 5/18/2011 9:42 AM, lkcl wrote: > > > he's got a good point, terry. breaking backwards-compatibility was a > > completely mad and incomprehensible decision. > > I see that I should take everything you (or Harris) say with a big grain > of salt;-). *lol* - i realise it's a hell of a lot of work to get a python interpreter to support two different grammars and syntaxes: you can appreciate that i'm in a better position than most to understand that [i've also done a port of python to gnu-win32 so am familiar with the codebase] now that the code for both has been written, tested and proven, the task of adding one t't'othr is a leetle less of a challenging task. there is one teeny tiny annoying challenge: namespace clashes in c, of functions and data structures between the two codebases. however, this isn't as bad as it first seems. it's only the "public" face (Python.h) which has to remain the same, and that can be taken care of by having data structures that are identical internally and externally (macros to the rescue) where the internal name is Python2_ and the external name Python_xxx. where it becomes less of a maintenance burden is when you say "ok, that's it: definitely end-of-the-road for all 2.N development, period". has anyone considered the idea of literally creating a Python2/ subdirectory in the python3 codebase, literally just dropping the entire python2.N code directly into it, renaming all functions and data structures, adding a "--2-compatible" switch to the python3 argc/ v and seeing what happens? no interoperability, no maintenance, no "compatibility" - just "support for python 2 directly in the python3 binary". l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 17, 5:38 pm, harrismh777 wrote: > is recompiled everything still works... not so in Python. The fact that > Python is free to morph gleely from PEP to PEP without responsibility or > accountability with the user base is what may kill Python, unless the > Python community gets a grip on this concept. he's got a good point, terry. breaking backwards-compatibility was a completely mad and incomprehensible decision. i don't believe version N of python is going to "die" due to changes - the sheer inertia of hundreds of millions of lines of code and hundreds of thousands of projects will make sure that's not going to happen, but it doesn't help. it doesn't matter what the leading-edge developers behind python _want_ to happen: it took 10+ years for python 1 and 2 to gain traction, and i believe that's the sort of order of magnitude lag-time to expect people world-wide to make decisions [to replace code]. you only have to look at how long it's taking IE6 to die :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 10:24 am, lkcl wrote: > > > otherwise please - really: just saying "give me support for python > > > 3.x or else" is ... > > > And I did not say that. > > yeah i know - i'm sorry: it just, with a little bit of "twisting", > could be construed as implying that. in case it wasn't clear, i apologise for doing that :) -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 6:29 am, harrismh777 wrote: > Terry Reedy wrote: > > > No, because I think you are exaggerating. That said, I think core > > Python is pretty close to 'complete' and I would not mind further syntax > > freezes like the one for 3.2. > > I am exaggerating only to the extent that someone can imagine folks > becoming just annoyed with PEP progress to drop the whole thing... I am > exaggerating only to the extent that we define 'it' as language death... > if the user base narrows, python's future is held tentative... on the > other hand, if the user base grows and campers are happy, then python's > future is more stable... I don't think this is an exaggeration... one thing that people are not aware of - because it normally simply does not make its way out into the public world: you're forgetting those people who "just use" python. they don't get onto public mailing lists, they don't develop free software projects. i've mentioned this story before, but it's worth repeating in this context. i worked in a military environment (NC3A) back in 2006-2007. the version of python that they were using was http://python two... point... ONE. six years after its release. why??? well, it went something like this. someone got the idea that doing a portal would be good. so they looked around, and found Zope. so, they evaluated the latest version somewhere around ooo april to june of 2001. ok they _started_ evaluating it. so, some four months later, after doing some coding examples, we're now up to august 2001, a decision has to be made by the internal client. they say "yep, go for it", but that took another four months (dec 2002). now we do 18 months of software development (july 2003) to produce a base package. now the code now has to be handed over to a team who perform security evaluations. this has to be paid for. another six months go by, and the security accreditation is received (dec 2004). but this was just for the "base" code: now we have deployment and actual product / portal development, and a maintenance cycle of 2 years (2006). now i'm called in to help with that maintenance and development cycle (2007). and throughout this time there is *no way* that they can upgrade from python 2.1, because it would cost another $EUR 10,000 to get the accreditation certificate. it's now 2011. for all i know, some TEN YEARS after python 2.1 was released, they're still using it. you ... _just_ don't normally hear about these kinds of deployments of free software, but it illustrates that a particular version can hang around for a hell of a long time. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 18, 2:33 am, Terry Reedy wrote: > On 5/17/2011 12:07 PM, lkcl wrote: > > > On May 4, 7:37 pm, Terry Reedy wrote: > >> On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote: > >>> pyjamasis a suite of projects, including a python-to-javascript > >>> compiler > >> As you well know, there is no such thing as 'python' when it comes to > >> compiling actual code. So please specify both in announcements here and > >> on the project homepagehttp://sourceforge.net/projects/pyjamas/ > >> which versions are supported. > > > [no response] > > I would still like to know. Do you fully support 2.7? It has many of the > same changes that are in 3.1 and even 3.2 so I can imagine it would be > difficult. sorry, terry, missed this out. there are two answers: a) at the moment a http://python.org 2.N interpreter is required to actually run the translator. if you use http://python.org 2.5 or 2.6 you do not need to use the "--internal-ast" option. if you use 2.4, 2.7 or above, you will need to use --internal-ast because we're heavily reliant on the internal c-based "compile" module [without the --internal-ast option enabled]. b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly been updated to 2.6. actual python syntax / features are therefore mostly 2.5, with someone having pointed out that "slice" has different return results it's hard to say exactly which is best to be picked, 2.5 or 2.6. nobody's needed slice until recently, so it's not an issue that's ever come up before. the thing is - it's worth reiterating: you just... really don't need as much python interoperability for user-interfaces when they're split along MVC lines. bear in mind that it's necessary to do that split: it's web browser technology, you can't *actually* execute things like psycopg or mysql in a web browser as javascript! so once you've divided that application into "python that runs the actual user interface" and "python on the other side of the AJAX barrier e.g. a django app" you're left with a far smaller task for the pyjs interpreter to have to tackle. this is why it's been so unnecessary to keep absolutely up-to-date with the full python development that's been going on, yet we still have people developing 10,000+ LOC 2 man-year pyjamas projects. that having been said, there _is_ the requirement to be "python strict" as well as "fast" - mutually exclusive of course. and there is someone working on getting the pyjs compiler and supporting libraries into shape in order to run the entire http://python.org regression test suite. there really are quite a lot of little sub- projects within the pyjamas project. > >> If you do not yet support 3.x, I request and recommend that you do so, > > > with the situation as it is, there is not a snowball in hell's chance > > that's going to happen. allow me to explain. > > Thank you for the explanation. not a problem. > You are right that I probably underestimated the work, yeah... i apologise for the somewhat-evident flabbergasted tone that may have been apparent in what could otherwise be considered to be a project outline / roadmap :) > though you have or will do some of what is > needed to fully support 2.7. weell... see above: it's kiinda unnecessary - it just depends on people's needs. if there are intelligent and willing people (like kees) who just come along and go "yep, that's nice, but it's not good enough for me: i'm going to make it so" then it'll happen. everyone else _not_ willing to put in the effort to make pyjs do what they want will just have to put up with the foibles. so if someone wants to do it, hell i'm not going to stand in the way - anyone who asks i give them commit rights, point them at the DEVELOPER.RULES and let them get on with it. > ... > > > otherwise please - really: just saying "give me support for python > > 3.x or else" is ... > > And I did not say that. yeah i know - i'm sorry: it just, with a little bit of "twisting", could be construed as implying that. > > "python 3 is the future of python" gimme a break!! > > Let's discuss that in a couple of years. :) i think... people forget that there are now two mutually- exclusively-incompatible programming languages out there, where the first six letters of the name of the programming language happen to be the same... l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.8alpha1 release
On May 4, 7:37 pm, Terry Reedy wrote: > On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote: > > > after a long delay thepyjamasproject -http://pyjs.org- has begun the > > 0.8 series of releases, beginning with alpha1: > > >https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/ > > >pyjamasis a suite of projects, including a python-to-javascript > > compiler > > As you well know, there is no such thing as 'python' when it comes to > compiling actual code. So please specify both in announcements here and > on the project homepagehttp://sourceforge.net/projects/pyjamas/ > which versions are supported. I do not really want to have to download > and experiment to determine whether to bother downloading. > > If you do not yet support 3.x, I request and recommend that you do so, with the situation as it is, there is not a snowball in hell's chance that's going to happen. allow me to explain. the python translator in pyjamas is heavily dependent on the "compiler" module (which is written in c) and is in turn, as you are no doubt aware, specifically dependent on the grammar file. the python translator for pyjamas 0.3 was 1,200 lines of code. thanks to some brilliant and dedicated work by kees bos, over something like a 6 month virtually full-time period, it's now somewhere around 5,000 lines of heavily-dense code in which very specific javascript optimisations have been encoded. then, on top of that, it is necessary to implement the data types that are supported in python 3.x, along with several built-ins (exceptions etc.). the basic implementation - pyjslib.py - is 6,700 lines of python code with in-built hand-optimised javascript, and it would be necessary to reimplement / re-work... and then support... that reimplementation. then, on top of that, there are a number of python-based reimplementations of various python modules, such as md5.py, re.py, string.py and so on, each of which would have to be double-checked for compatibility with their python 3.x counterparts. do they exist, have they been rewritten, modified etc.` then, on top of that, it is necessary to run the pyjamas UI code, which is some 15,000 lines of code, along with the other libraries such as GChart, through lib2to3, and then to double-check them. then, on top of that, it is necessary to run the examples - of which there are 70 - again through lib2to3. i've just done a "wc" on the examples source code: it comes to a whopping total of 60,000 lines of code. so you have to do all this work, and really it's impossible to begin realistically checking that it works until you get to the LibTest example (which is the main test suite, comprising some 3,000 or so regression tests), and once you've done all that work you now need a userbase and also some maintainers. and, when it comes to doing a release, you need to test all 70 examples in a matrix of 14 browsers plus 4 desktop runtime engines, and the browsers you need to recompile three times - with -O (optimised), --strict (python-compliant) and there's one more, i forget its name, it's designed to minimise the amount of javascript generated. to support 3.x therefore requires a complete and utter rewrite, and then a hell of a lot of work on top of that. it's basically supporting a totally separate language, and so is basically a completely new project. i know you mean well, but... you've drastically underestimated quite how much effort has gone into the pyjamas project - just look at the ohloh statistics for goodness sake! it's listed as having had 31 man-years gone into it! http://www.ohloh.net/p/pyjamas so if you can find the money to get people paid to create a python 3.x to javascript compiler, which will require approximately twelve to fifteen man-months of full-time dedicated programming effort, please do speak up! otherwise please - really: just saying "give me support for python 3.x or else" is ... honestly - it's a free software project, _not_ a paid-up corporate google/nokia/ibm/redhat/etc. funded project: you know the score, and you know the drill. now. leaving _that_ aside, there happens to be absolutely no really good compelling reason to support python 3.x in the first place. "python 3 is the future of python" gimme a break!! [so why is archlinux the only linux distribution that's converted over to run everything off of python 3.x?] the thing is: there aren't really any major dependencies to "get in the way" in pyjs. as in: it's entirely self-sufficient [it has to be]. even the installation has its own sandbox system. the only dependency *is* python 2.N, and when daniel kluev completes his GSoC2011 project, that'll be a "bootstrap" into javascript, including the translator itself being compiled into javascript, and then not even python 2.N will be a dependency! the bottom line is this: somewhere in the next 8 to 10 years, python 2.N will be deprecated in all but the most die-hard places. at *that* time, it will have been worthwhile
Re: pywebkit - python bindings for webkit DOM (alpha)
apologies for the 3 copies of the post: mail.python.org's SMTP service was offline yesterday. just a quick update: XMLHttpRequest support has been fixed today, and the correct version of libsoup discovered which actually works. that puts PythonWebkit into a "useful and useable" state, despite being only 15 days old. further development is still needed, but it's still pretty exciting to be back to where the original python webkit bindings code was, from 2008, minus the cruft from the intermediate glib/gobject layer, in such a short amount of time. l. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pywebkit - python bindings for webkit DOM (alpha)
i've been kindly sponsored by http://www.samurai.com.br to create direct python bindings to webkit's DOM: http://www.gnu.org/software/pythonwebkit/ the significance of this project is that it makes python a peer of javascript when it comes to manipulating HTML through DOM functions (including gaining access to the full features of HTML5 for example). anything that can be done with javascript (such as getElementsByTagName, appendChild etc.) can be done with python, in a declarative programming style (not as < script language="python" >). that means that the powerful features of HTML5 that were formerly pretty much exclusively available to javascript programmers are now equally available to python programmers, and webkit is known as being especially suited to embedded environments. anyone who has been following pywebkitgtk or pyjamas development will be aware that the previous python webkit DOM bindings, written in 2008, were based on top of glib/gobject bindings and used python-gobject to autogenerate them. whilst this approach worked, its future was made slightly awkward when the development of the gobject bindings were kindly taken over by free software developers who have been working hard to incorporate the full features of the original gobject bindings into webkit for almost a year, now. the pythonwebkit project therefore begins again, with *direct* access to webkit DOM functions and properties instead of going via an intermediate layer such as gobject. the source code for the pywebkitgtk project has been directly incorporated into the pythonwebkit project, making it a much simpler prospect to build. that does not mean that it's easy - just easier! for build instructions, please read the instructions at http://www.gnu.org/software/pythonwebkit/ which recommend reading of the original webkit build instructions on the original webkit developer web site, with specific advice on the additional python requirements. (please note that the ongoing development focus is on linux and embedded linux systems: windows and macosx developers are very much "on their own" as far as build procedures are concerned, but macosx developers are best advised to start from darwinports and to go from there. windows developers: good luck. send us a postcard from whatever loony bin you end up in, if they allow you access to crayons). for those people interested in pyjamas (http://pyjs.org), pyjamas desktop has already been updated accordingly, and is already useable with pywebkit. please note that this is a very early announcement, with quite a lot still left to do, but whilst there are known issues, the project is definitely at the "working" state and so is worthy of an announcement if anyone is interested in testing and contributing or just seeing what the fuss is about. l. p.s. it's worthwhile pointing out, for anyone who is interested, that if you wish to access a browser engine's DOM model on windows, it is much easier to use python-COM bindings to MSHTML than it is to try building webkit with python bindings on windows - but should you ever succeed in building pythonwebkit on windows, please do get in touch. if however you See The Light and realise in good time that it's a train coming straight at you, and decide to use python COM instead, i recommend looking at pyjd/mshtml.py and associated code in the pyjamas project - http://pyjs.org - and beginning from there. compiling webkit (and xulrunner) on windows really is that bad, and incorporating python into the mix really is likely to push your sanity off the edge of a cliff. if you succeed however, there are quite a lot of people who will be extremely grateful for your sacrifice, and who will come visit you and bring you flowers and children's colouring picture books on a regular basis. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pywebkit - python bindings for webkit DOM (alpha)
From: l...@lkcl.net To: python-list@python.org i've been kindly sponsored by http://www.samurai.com.br to create direct python bindings to webkit's DOM: http://www.gnu.org/software/pythonwebkit/ the significance of this project is that it makes python a peer of javascript when it comes to manipulating HTML through DOM functions (including gaining access to the full features of HTML5 for example). anything that can be done with javascript (such as getElementsByTagName, appendChild etc.) can be done with python, in a declarative programming style (not as < script language="python" >). that means that the powerful features of HTML5 that were formerly pretty much exclusively available to javascript programmers are now equally available to python programmers, and webkit is known as being especially suited to embedded environments. anyone who has been following pywebkitgtk or pyjamas development will be aware that the previous python webkit DOM bindings, written in 2008, were based on top of glib/gobject bindings and used python-gobject to autogenerate them. whilst this approach worked, its future was made slightly awkward when the development of the gobject bindings were kindly taken over by free software developers who have been working hard to incorporate the full features of the original gobject bindings into webkit for almost a year, now. the pythonwebkit project therefore begins again, with *direct* access to webkit DOM functions and properties instead of going via an intermediate layer such as gobject. the source code for the pywebkitgtk project has been directly incorporated into the pythonwebkit project, making it a much simpler prospect to build. that does not mean that it's easy - just easier! for build instructions, please read the instructions at http://www.gnu.org/software/pythonwebkit/ which recommend reading of the original webkit build instructions on the original webkit developer web site, with specific advice on the additional python requirements. (please note that the ongoing development focus is on linux and embedded linux systems: windows and macosx developers are very much "on their own" as far as build procedures are concerned, but macosx developers are best advised to start from darwinports and to go from there. windows developers: good luck. send us a postcard from whatever loony bin you end up in, if they allow you access to crayons). for those people interested in pyjamas (http://pyjs.org), pyjamas desktop has already been updated accordingly, and is already useable with pywebkit. please note that this is a very early announcement, with quite a lot still left to do, but whilst there are known issues, the project is definitely at the "working" state and so is worthy of an announcement if anyone is interested in testing and contributing or just seeing what the fuss is about. l. p.s. it's worthwhile pointing out, for anyone who is interested, that if you wish to access a browser engine's DOM model on windows, it is much easier to use python-COM bindings to MSHTML than it is to try building webkit with python bindings on windows - but should you ever succeed in building pythonwebkit on windows, please do get in touch. if however you See The Light and realise in good time that it's a train coming straight at you, and decide to use python COM instead, i recommend looking at pyjd/mshtml.py and associated code in the pyjamas project - http://pyjs.org - and beginning from there. compiling webkit (and xulrunner) on windows really is that bad, and incorporating python into the mix really is likely to push your sanity off the edge of a cliff. if you succeed however, there are quite a lot of people who will be extremely grateful for your sacrifice, and who will come visit you and bring you flowers and children's colouring picture books on a regular basis. -- http://mail.python.org/mailman/listinfo/python-list
fairly urgent request: paid python (or other) work required
i apologise for having to contact so many people but this is fairly urgent, and i'm running out of time and options. i'm a free software programmer, and i need some paid work - preferably python - fairly urgently, so that i can pay for food and keep paying rent, and so that my family doesn't get deported or have to leave the country. i really would not be doing this unless it was absolutely, absolutely essential that i get money. so that both i and the list are not unnecessarily spammed, please don't reply with recommendations of "where to get jobs", unless they are guaranteed to result in immediate work and money. if you have need of a highly skilled and experienced python-preferring free-software-preferring software engineer, please simply contact me, and tell me what you need doing: there's no need for you to read the rest of this message. so that people are not offended by me asking on such a high-volume list for work, here are some questions and answers: Q: who are you? A: luke leighton. free sofware developer, free software project leader, and "unusual cross-project mash-up-er" (meaning: i spot the value of joining one or more bits of disparate "stuff" to make something that's more powerful than its components). Q: where's your CV? A: executive version of CV is at http://lkcl.net/exec_cv.txt - please don't ask for a proprietary microsoft word version, as a refusal and referral to the "sylvester response" often offends. Q: what can you do? A: python programming, c programming, web development, networking, cryptography, reverse-engineering, IT security, etc. etc. preferably involving free software. Q: what do you need? A: money to pay rent and food. at the ABSOLUTE MINIMUM, i need as little as £1500 per month to pay everything, and have been earning approx £800 per month for the past year. a £5000 inheritance last year which i was not expecting has delayed eviction and bankruptcy for me and my family, and deportation for my partner and 17 month old daughter (marie is here in the UK on a FLR/M visa) Q: why are you asking here? A: because it's urgent that i get money really really soon; my family members are refusing to assist, and the few friends that i have do not have any spare money to lend. Q: why here and not "monster jobs" or "python-jobs list" or the various "recruitment agencies"? A: those are full-time employment positions, which i have been frequently applying for and get rejected for various reasons, and i'm running out of time and money. further interviews cost money, and do not result in guaranteed work. i need work - and money - _now_. Q: why here and not "peopleperhour.com"? A: if you've ever bid on peopleperhour.com you will know that you are bidding against "offshore" contrators and even being undercut by 1st world country bidders who, insanely, appear to be happy to do work for as little as £2 / hour. Q: why are you getting rejected from interviews? A: that's complex. a) i simply don't interview well. people with the classic symptoms of asperger's just don't. b) my daughter is 17 months old. when i go away for as little as 3 days, which i've done three times now, she is extremely upset both when i am away and when i return. i think what would happen if i was doing some sort of full- time job, away from home, and... i can't do it. subconsciously that affects how i react when speaking to interviewers. Q: why do you not go "get a job at tesco's" or "drive a truck"? A: tescos and HGV driving etc. pay around £12 per hour. £12 per hour after tax comes down to about £8 to £9 per hour. £9 per hour requires 35 hours per week to earn as little as £1500. 35 hours per week is effectively full-time, and means that a) my programming and software engineering skills are utterly, utterly wasted b) my daughter gets extremely upset because i won't be at home. so you get the gist, and thank you for putting up with me needing to take this action. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: multitask http server (single-process multi-connection HTTP server)
On Jul 13, 12:00 pm, Luke Kenneth Casson Leighton wrote: > but... not being funny or anything, but basically i'm done already > :)multitaskhttpdworks, it doesn't need stackless, i completed a JSONRPC > service last night, i'll add POST of multi-part forms today, and i > have everything that [GNUmed] will need. ok instead of adding this to httpd.py i created an HTTP proxy out of multitaskhttpd. i also cobbled together an example JSONRPC Server which is highly likely to be used in gnumed, now. this modified version of SimpleJSONRPCServer.py i had to rip bits of BaseHTTPServer.py and add in Connection Keep-Alives on every response. so, send_error needed modding/replacing, as did send_head, list_directory and so on, all with a view to making sure that the HTTP proxy is "happy". the reason why the proxy works is because the incoming HTTP connection results in an HTTP/1.1 proxy connection with Connection: Keep-Alive set. so, even if the user's browser drops the connection, the proxy permanently keeps open the connection to the upstream HTTP server. in the case of the standard SimpleHTTPServer.py and so on that results in the handle_request() loop basically serving that same user _forever_. well... it would, if it wasn't for the fact that the standard version of send_error() in BaseHTTPServer.py does "Connection: Close", hence the reason why i had to replace it. so, yeah - now you can do truly dreadful things like... create a massive in-memory data structure and never have to serialise it because the back-end process will _still_ be around pretty much forever... and you can keep doing that until the server runs out of memory. hurrah! l. -- http://mail.python.org/mailman/listinfo/python-list
Re: grailbrowser now running under python 2.5 (probably above too)
On Jul 11, 10:39 pm, "Martin P. Hellwig" wrote: > On 07/11/10 04:59, Luke Kenneth Casson Leighton wrote:> source at: > >http://github.com/lkcl/grailbrowser > > > $ python grail.py (note the lack of "python1.5" or "python2.4") > > > conversion of the 80 or so regex's to re has been carried out. > > entirely successfully or not is a matter yet to be determined. always > > a hoot to try browsinghttp://www.bbc.co.ukorhttp://www.youtube.com > > with a browser from 11+ years ago, it still cannot be resisted as > > grail is the only working graphical web browser in the world written > > in pure python [pybrowser is still in development, stalled]. > > > l. > > Congrats! > Are you planning to take over the world with grail and pyjs? :-) mwahaahhah basically, yes. i'm fed up with the mozilla foundation, who have trashed python-xpcom _just_ at the point where i demonstrated its usefulness: the only reason things still work across linux distributions is due to inertia as the distros are still offering xulrunner-1.9.1, and i'm definitely fed up with the webkit developers, one in particular, whose treatment of and attitude to the work that i did to get python bindings to the DOM of webkit was beyond atrocious. so, python-based web browser it is, implement the W3C DOM API with it. hack it about, combine paul bonser's pybrowser back-end (which was where paul did most of the work, and stalled on the front-end), job done, one compliant python browser supporting W3C TR1,2 and 3 and if we're reaaallly lucky i maybe add some HTML5 features too. just don't expect it to be quick! l. -- http://mail.python.org/mailman/listinfo/python-list
Re: grailbrowser now running under python 2.5 (probably above too)
On Jul 11, 5:44 am, rantingrick wrote: > On Jul 10, 10:59 pm, Luke Kenneth Casson Leighton > > wrote: > > source at:http://github.com/lkcl/grailbrowser > > > $ python grail.py (note the lack of "python1.5" or "python2.4") > > > conversion of the 80 or so regex's to re has been carried out. > > entirely successfully or not is a matter yet to be determined. always > > a hoot to try browsinghttp://www.bbc.co.ukorhttp://www.youtube.com > > with a browser from 11+ years ago, it still cannot be resisted as > > grail is the only working graphical web browser in the world written > > in pure python [pybrowser is still in development, stalled]. > > > l. > > Congratulations on this effort Luke. However you know what project i > would really like to see the community get around? ...dramatic pause > here... a cross platform Python file browser! weeelll... you _could_ always just use grailbrowser :) it does still support file:// so it lists directories, shows text files and downloads anything it doesn't understand. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: multitask http server (single-process multi-connection HTTP server)
On Jul 12, 9:52 pm, Gelonida wrote: > Hi lkcl, > > Do you have any documentation or overview for your project? git clone git://pyjs.org/git/multitaskhttpd.git i only started it today, but yes, there's a README. the primary reason it's being developed is because GNUmed are looking to create a web service but they want to use the same psycopg2-based middleware that's taken them pretty much forever to develop. see my reply to geremy condra for more details. if this turns out to be something that _really_ hasn't been done before, then i'm happy for other people to pitch in and help out. > Questions I would be interested in: > - List of features already working * simple HTTP GET of files and subdirs (because i blatantly copied SimpleHTTPServer.py) * JSONRPC services (i blatantly copied SimpleJSONRPCServer.py, it's something i found, it's based on SimpleXMLRPCService.py) > - list of features under development the time between "under development" and "in future" is so short it's hardly worthwhile stating. i added JSONRPC in about 90 minutes for example. tomorrow i'll add HTTP POST multi-part forms and it will take me about... 50 mins i should imagine, by looking at something like turbogears or django. i'm not going to "waste time reinventing" stuff when i can pretty much cut/paste it. web servers have been _done_ already - it's just that cooperative multitasking seems most definitely _not_ to have been done before. > - list of features being in in the near future * HTTP POST with multi-part forms (just like standard web frameworks) * a better API once i have a clearer idea of what's needed * use of regex matching on apps, just like django urls.py l. -- http://mail.python.org/mailman/listinfo/python-list
multitask http server (single-process multi-connection HTTP server)
for several reasons, i'm doing a cooperative multi-tasking HTTP server: git clone git://pyjs.org/git/multitaskhttpd.git there probably exist perfectly good web frameworks that are capable of doing this sort of thing: i feel certain that twisted is one of them. however, the original author of rtmplite decided to rip twisted out and to use multitask.py and i'm one of those strange people that also likes the idea of using 900 lines of awesome elegant code rather than tens of thousands of constantly-moving-target. one of the things that's slightly unfortunate is that i'm going to have to copy SimpleHTTPServer.py and slightly modify it; CGIHTTPServer.py as well. this is Generally Bad Practice. can anyone think of a way of monkey-patching or otherwise using SimpleHTTPRequestHandler and CGIHTTPRequestHandler and overriding the base class from which those two are derived? i have had to pull bits out of BaseHTTPRequestHandler to make them use the "yield" logic of multitask.py already, which was painful enough. ideas, anyone? l. -- http://mail.python.org/mailman/listinfo/python-list
python ctypes to int main(int argc, char *argv[])
hi, i need to convert an application (fontforge) to a python library. yes, libfontforge is already done as is libgdraw (fontforge-pygtk) but i need to make fontforge the _application_ a python application, using the same ctypes trick that's already done. my question is, therefore, how do i specify a ctypes wrapper around the standard int main(int argc, char *argv[]) which i am (obviously) going to move to a (new) c library? many thanks, l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Should I Learn Python or Ruby next?
On Tue, Jun 22, 2010 at 6:58 PM, Josef Tupag wrote: > Before I really dive in, though, I'm curious to hear what others think about > the choice between these two languages. i think one good illustration is a story i heard from someone who had learned a hell of a lot of programming languages, but didn't know python. he decided one day to try it and, without looking closely at a manual, literally guessed his way through the syntax: "how do you do lists? let's try square brackets. oh look, that worked! ok.. um... how do you do arrays? let's try curly brackets. oh look, that worked! ok, what are they called? ahh, dictionaries. how quaint. ok, how do you do if statements? ok let's try the woordd if! ok, that worked - hmmm, how do you terminate them? let's tryyy... a colon - great - that worked! hmmm, what's with this three dots on the python prompt, now? ok, let's put in some spaces. ah ha! that worked!" when compared to other programming languages, three things stand out clearly for me: 1) it's actually readable. especially when you use colour syntax highlighting (such as vim) which i thoroughly, thoroughly recommend: giving yourself those visual cues that keywords are in yellow, comments are in blue, strings in purple, it increases productivity *massively* as you scan through reams of text, jumping to the correct location, finding what you want, based on blocks of colour *first*, and the characters second. 2) it's beautiful / tidy. the use of fixed/identical indentation to specify a "block" _forces_ the developer to be "tidy". i've seen some developers - perl mostly - _actively_ discouraged and hostile to perl because of this, and to be frank, that's a good thing. 3) it's a dynamic and a compact language. i remember seeing that comparison of python and lisp, which happened to include some java statements as well. _six_ lines of java to do what you can do in a few characters of python - and about two in scheme :) so whilst ruby may be dynamic and compact, it's not beautiful, readable or obvious as to what's going on. i look at a python program, and it uses actual... like... y'know... words that make sense. i look at a ruby program and i simply cannot say the same, not even if you put code which is supposed to do exactly the same job. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 1:07 pm, superpollo wrote: > mind you, i am no python expert, but i really look forward to seeing > pyjamas in the stdlib :-) anytime soon? *choke* :) ... weelll... let me answer that as if it's serious. you'd have to: a) define http://python.org as including a javascript target for its output. given that pypy have (or had) this, that's not entiiirely outside of the realms of possibility. b) include ooo 10,000 lines of base UI widget libraries, which are all written in pure python. again, not so bad. c) completely rule out any possibility of pyjd because whilst the win32 dependency is python-comtypes (which depends on ctypes which whoops rules _that_ out) the free software dependencies are a choice between pygtk2 plus xulrunner, libcairo, python-cairo, gobject plus python-gobject and many more plus python-xpcom _plus_ python-hulahop, or webkitgtk plus pywebkitgtk plus again many of the same pygtk dependencies, each of which will come to around a whopping 30mb download comprising some 90 to 100 separate libraries in each case... and that's without dealing with the multitude of licenses. ... and without pyjd it's somewhat a pointless exercise. overall i think this just reaffirms that the minimalist but extensible python-tk approach really does have distinct advantages. thus, at last, we come back full circle to the original question. hooray! l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 15, 2:47 pm, Steven D'Aprano wrote: > On Tue, 15 Jun 2010 05:57:13 -0700, lkcl wrote: > > to be honest, if you don't put any effort in to use the appropriate > > "lovely-prettiness" panels you can end up with something truly "90s- > > esque". but with a little effort you can do round-edged lovely colour > > tabs: > > http://pyjs.org/examples/tabpanelwidget/output/Tabs.html > > All I get is a plain page with no content. No images, no text, nothing. > Shouldn't you at least include "This site requires Javascript to work"? naaah. that would mean adding one extra line with a noscript tag to the html loader page, increasing size of each of the example loader pages by a whopping ten percent! :) > You know, I like the idea of pyjamas, but I am so utterly sick and tired > of javascript and flash running amok and web developers who try to take > over my browser that I've turned them off. _hurrah_! i used to write web apps entirely server-side, no AJAX, no JS, nothing, precisely to cater exactly for this feeling, which i entirely agreed with. then i went absolute 100% the other way. i had _nothing_ good to say about javascript, but by abstracting out to python, i found the "wiggly path" that leverages its powerful bits without falling into the trap of the god-awful mess that causes you to rightly switch off JS entirely. fortunately, for you, with pyjd you're in luck: python bindings to DOM, doing exactly the same job as the equivalent JS - all JS gooone. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 9:00 pm, Stephen Hansen wrote: > On 6/14/10 1:00 PM, lkcl wrote: > > what we typically recommend is that _even_ though you're going to run > > the application "desktop" - as pure python - you still use JSONRPC [or > > XmlHTTPRequest if JSONRPC is overkill]. so, _even_ though it's a > > desktop application, you still run a local 127.0.0.1 web service (even > > python -m SimpleCGIServer.py will do the job!) > > > rick's article is highly illustrative on all these points: > > http://www.ibm.com/developerworks/web/library/wa-aj-pyjamas/ > > Hmm. Depending on just how rich of a UI is possible, this is a slightly > compelling idea. to be honest, if you don't put any effort in to use the appropriate "lovely-prettiness" panels you can end up with something truly "90s- esque". but with a little effort you can do round-edged lovely colour tabs: http://pyjs.org/examples/tabpanelwidget/output/Tabs.html > Right now, I have to essentially maintain two separate > code-bases: the desktop client and the web application. deep joy! > In my scenario, > both are actually lightweight (though not truly thin) clients to a > master application server existing Elsewhere, that does the heavy > lifting and manages all its users. > > Being able to take a code base and provide it to users as a > traditional-seeming desktop application that works desktopy for them, > with-- it sounds like-- two separate processes, one which is Python and > is "serving" data, and more importantly accessing the MCP and getting > instructions and doing its "lightweight" local lifting-- and another > which is just a UI that communicates to that local server? basically, yes. splitting things more along the traditional MVC lines. the M being the web server with JSONRPC to do traditional Create-Update-Retrieve-Delete etc. and the VC bit being in pyjamas, talking JSONRPC to the server *even* on the desktop version! > Then one would run basically the same code on a server to allow remote > access on some internet-accessible server, that sounds like what you're > implying is possible? yes, even on the desktoppy version (because it's the same app) > This time the server is still there, but the > client UI is converted into pure JS and shipped to the persons machine. yup. > That sounds too good to be true. yup, it does. how can one person, a free software developer, have come up with something like "The Holy Grail" of software development, right? when all the money in the world, from ibm, adobe, microsoft, google, nokia and so on _hasn't_ managed it, in what... 20 years of computer science, right? i must be some sort of egomaniac, attention- seeker, snake-oil-seller or just an outright liar, right? those _are_ supposed to be rhetorical questions :) > I sort of have to be reading too much > into what you're saying. no, you got it. does what it says on the tin. the "fly in the ointment" is that the success of pyjamas desktop is critically dependent on its underlying DOM-bindings technology. ironically, the non-free and proprietary dependence on MSHTML works perfectly, whilst there are webkit developers *actively* destroying the webkit-glib/gobject port, and the mozilla foundation developers are trying desperately hard to break XPCOM (they've already side-lined python-xpcom as "third party" now) because they're so "losing" so badly to webkit that they are desperate to sacrifice everything to get speed, speed, speed. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: python XMLHttpRequest
> so they _had_ to put the glib/gobject bindings in, after all that > effort spent fighting tooth and nail to prevent it... and not having > access to the key developer who worked on it (because of censorship) > it's been a bit of a bitch for them, and it's only about 80% complete, > after 6 months (the initial work only took 10 weeks!) important afterthought: xan, who was responsible for working on the webkit glib/gobject bindings after the webkit censorship engineered and enacted by mark rowe, has been absolutely fantastic, along with the people who worked with him to review the patches. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 7:30 pm, Stephen Hansen wrote: > On 6/14/10 11:47 AM, lkcl wrote: > > > On Jun 14, 4:17 pm, Stephen Hansen wrote: > > yes. that's effectively what pyjs applications are about: as much > > HTML/CSS as you can stand, then _absolute_ pure javascript from there- > > on in... only using a compiler (python-to-javascript) so as not to go > > completely insane - and, from the rest of your message, i _know_ you > > know what i'm talking about, there :) > > Yeah. It sounds very interesting. I just wish it, like, somehow bundled > webkit cross-platformly. :) _that's_ a long story - a brief insight into 8 months of hell i posted in another message on this thread... > > to be absolutely honest, i very rarely even write my own widgets: i > > advocate that people, myself _especially_ myself included, perform > > literal line-for-line translations of GWT widgets from java to > > python. why? because, again: on the basis that google have tons of > > money to put into GWT widgets, doing full regression tests, and have > > thousands of users, they can afford to get the widget right across all > > the browsers. ergo, why duplicate that effort - just code-translate > > it verbatim! > > > oh, btw, that's turning into quite a powerful project on its own: the > > goal is to have a fully automated java-to-python translator! > > > http://github.com/thoka/java2python > > Somehow this is getting perverse. Java, to Python, to JavaScript. It > just sounds sort of incestuous. :) oh i haven't mentioned the javascript-to-python converter yet, have i? *lol*. am still looking for a good BNF / parser in python, for that one. > Well, yes. I have some experience with extjs (and making some pretty > fantastic real-world seeming apps on the web with it), and yeah, > The current project occupying my time involves a fairly complicated mix; > on the server-side we have Pylons, but its interfacing with an external > application server, so about half of the Pylons layers are "outsourced" > (i.e., data and model access). > > Then the web interface is ExtJS. Its just getting very, very -- ungainly > from a maintenance point of view. ooh. ouch. we've had people wanting to wrap extjs in pyjamas. i told them NO don't for god's sake do it. it's _hundreds_ of thousands of lines of javascript; looking at the GWT-EXTJS wrapper, the "startup" code in javascript is a whopping 8,000 lines (which was more than the entire pyjamas codebase at the time!) and the rest of the "wrapper" code i believe is some 80,000 lines of java. then there's the issue that, apart from all that code to maintain, you now have a whopping great 2.5mbyte javascript dependency, where you'd need, if there was a bug in that, an expert javascript programmer... so whilst pyjamas UI widgets are somewhat at the level of "extjs 0.01", at least there is http://puremvc.org (which yes, that _does_ compile to javascript cleanly!) which you can combine with e.g. the Grid Widget and a few more prettifying widgets, in order to create the kinds of looveliness that is extjs. > Maybe on its next iteration I'll look > into pyjamas. mmm, that leaves you with an all-or-nothing approach. there's a trick you could do, which involves using a pyjamas ui Frame widget, where you could convert the site one bit at a time. that's been done before now. if you're already using an AJAX approach in the back-end server (which it sounds like you are) then you'll be much much further ahead than many pyjamas converts: all you'd need to do is reimplement page- by-page the front-end widgets. ok gotta go, baby's dragging me away. l -- http://mail.python.org/mailman/listinfo/python-list
python XMLHttpRequest
> all the methods by which you would have to deal with that GUI loop > problem have to be asynchronous _anyway_... aaand, what the heck, why > not just go with the flow and use the pyjamas.HTTPRequest or > pyjamas.JSONService recommended services, neh? sorry to be adding stuff after-the-fact, but this is so ironic and nuts i have to point it out. underneath pyjamas.HTTPRequest and pyjamas.JSONService, that's XmlHttpRequest... no not XmlHttpRequest from javascript/web-browsers: XmlHttpRequest _from python_! in the MSHTML port, it's actually a COM interface wrapper around the functions found in MSXML3 or MSXML6 DLL :) and ys, it actually works, in exactly the same way, identical in virtually every respect across all the pyjd ports (with the exception of some bugs in XulRunner/XPCOM), as the exact same javascript object found in web browsers, with the exact same functions, event-handling callbacks and so on. as an aside to that: i don't recommend you go looking into it (400 comments+ on a bugzilla...), but the development of the glib/gobject bindings were a total nightmare. not from a technical perspective, but from what can only be described as ... well, one of the developers decided quite early on that i must be some sort of egomaniac, and that i had to be "taught a lesson". this "lesson" involved finding any excuse, method or rule (existing or made up) to jeopardise the webkit- gtk glib/gobject bindings. it didn't matter what it was - the answer "no" _would_ be found. i call this "technical bullying". in the case of the XmlHttpRequest functionality, the justification was simple: "there are perfectly good gtk networking libraries out there. bug closed, that's the end of it. I, Mark Rowe, Have Spoken" (implication: off you dip-). it took one of mark rowe's own colleagues, maciej, to point out that the lack of XmlHttpRequest functionality for the objective-c webkit bindings had forced at least one iPhone development team, to his knowledge, to write an "XmlHttpRequest" look-alike - in objective-c! and that, furthermore, _without_ the bindings to "real" XmlHttpRequest, that reimplementation's effectiveness was severely curtailed. maciej pointed out that the "real" XmlHttpRequest has access to "onload" event notification, XSS security, and all the other stuff that makes XmlHttpRequest so powerful: interaction with the web browser engine and its internal events, workings and state information. now multiply that one experience by 300+ DOM objects, 2000+ W3C DOM functions and 20,000 W3C DOM properties, all of which had to have glib/ gobject bindings, and you can see how easy it was for one egoistic webkit developer to jeapordise the chances of success of the pywebkitgtk project, based on their "superior technical knowledge" and, if that wasn't superior enough, judicious use of turning a blind eye to legitimate technically sound arguments. the _only_ reason that, after nearly 18 months of delay, webkit now has _partial_ glib/gobject bindings that are useless as far as pyjamas- desktop is concerned, is that a) i wore them down: the amount of time being spent "countering" eevery single fucking argument was just far too time-consuming b) i embarrassed them: the implications of being banned from webkit and the manner in which that censorship was carried done became shameful to them c) this is the important bit: lots of people *other than me* have been clamouring for webkit-glib/gobject bindings. so they _had_ to put the glib/gobject bindings in, after all that effort spent fighting tooth and nail to prevent it... and not having access to the key developer who worked on it (because of censorship) it's been a bit of a bitch for them, and it's only about 80% complete, after 6 months (the initial work only took 10 weeks!) upshot is: if anyone wants python bindings to webkit including the full suite of DOM objects, you're going to have to get onto webkit-dev mailing list and bitch like a trooper. nicely, mind :) the more people ask (and raise bugreports about it), the less they can say "no". l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 7:30 pm, Stephen Hansen wrote: > On 6/14/10 11:47 AM, lkcl wrote: > > > On Jun 14, 4:17 pm, Stephen Hansen wrote: > > yes. that's effectively what pyjs applications are about: as much > > HTML/CSS as you can stand, then _absolute_ pure javascript from there- > > on in... only using a compiler (python-to-javascript) so as not to go > > completely insane - and, from the rest of your message, i _know_ you > > know what i'm talking about, there :) > > Yeah. It sounds very interesting. I just wish it, like, somehow bundled > webkit cross-platformly. :) > > > to be absolutely honest, i very rarely even write my own widgets: i > > advocate that people, myself _especially_ myself included, perform > > literal line-for-line translations of GWT widgets from java to > > python. why? because, again: on the basis that google have tons of > > money to put into GWT widgets, doing full regression tests, and have > > thousands of users, they can afford to get the widget right across all > > the browsers. ergo, why duplicate that effort - just code-translate > > it verbatim! > > > oh, btw, that's turning into quite a powerful project on its own: the > > goal is to have a fully automated java-to-python translator! > > > http://github.com/thoka/java2python > > Somehow this is getting perverse. Java, to Python, to JavaScript. It > just sounds sort of incestuous. :) > > But also worth looking into for my next web project. > > >> Traditional GUI models vs the web layout model are just alien to one > >> another, and the latter is -extremely- convoluted. > > > we've found that there's a third "hybrid" case, and it's hinted at > > through RIA javascript libraries such as extjs: a traditional GUI > > model *implemented* as a web app. > > > so those RIA JS libraries are not "vs", they're _both_. except... > > javascript has its own headaches, so that's why both pyjamas and GWT > > remove _those_ headaches, by using language translators. > > Well, yes. I have some experience with extjs (and making some pretty > fantastic real-world seeming apps on the web with it), and yeah, > removing Javascript headaches is a very interesting goal. (Pet peeve to > end all pet peeves: trailing commas in objects breaks IE. I always leave > trailing commas, always, in Python code: makes adding stuff easier > later. And I can't shake doing it in my javascript instinctively). > > The current project occupying my time involves a fairly complicated mix; > on the server-side we have Pylons, but its interfacing with an external > application server, so about half of the Pylons layers are "outsourced" > (i.e., data and model access). > > Then the web interface is ExtJS. Its just getting very, very -- ungainly > from a maintenance point of view. Maybe on its next iteration I'll look > into pyjamas. > > >> Now, I do not know QT, but I know wx -- which is implemented > >> in temrs of gtk, so somehow the wx team got it working on GTK. > > >> wx uses a complicated recursive layout engine (unless you're mildly nuts > >> and try to do absolute layouts) which in all essence does *exactly* what > >> you are describing there. > > > oooOo. that's _very_ interesting to hear. i'd assumed that there > > wouldn't be anything "beneficial" that wx would bring to the table, by > > using gtk. ha. that might be worthwhile doing a pyjd-wx port, then, > > after all. hmm. > > Well, I may have overstated it a little bit by mistake. he he. rats! > wx does not require you use this model, and it does not do it on its own > -- you do have to "design" the flow a little bit. > > wx has two separate containment hierarchies. The first is a > hierarchical, parent->child relationship. This is what a lot of people > think is its layout: but its not. It has nothing to do with layout, but > instead its more about event propagation. oh crap, yeah, i forgot about that. event propagation rules. darn it. y'know what? forget it - i might as well, seriously, help implement an entire modern web browser in python, and use that. > Ahem. /Rant. I'm not saying its the best layout system in the world, but > like your DOM/HTML example -- its resolution independant (and > cross-platform), so you can start resizing things and changing the > window size and it all reflows things as the window resizes. Lots of > toolkits can do that, but I just really find the sizer approach both > flexible and very powerful to achieve very usable interfaces. (And its > very web-like, exc
Re: GUIs - A Modest Proposal
On Jun 14, 5:57 pm, rantingrick wrote: > I'll have to very much agree with this assessment Stephan. There > exists not elegant API for these "web" UI's. The people over at > SketchUp (my second love after python) have this problem on a daily > bases with WebDialogs. Even the javascript gurus have a dificult time > juggling javascript, CSS, and Ruby code to make these grumpy beasts > come to life, and when they do it ain't really pretty. ah. again, the "recommended" pyjamas development model vs the "standard" development model comes to the rescue, here. in a pyjamas app, the app loads ONCE and ONLY ONCE, as one whopping great javascript behemoth which can be somewhere around 2mb if the original python (pyjamas) source is around... 15 to 20,000 lines of code. from thereon in, you DO NOT do *any* HTML page "GETs": it's a one- time static HTML/JS load, and THAT's IT. the only further interaction that we recommend is first and foremost JSONRPC (and so, out of the 30 or so pyjamas wiki pages, about 10 of them involve HOWTOs for interacting with django, pylons, web.py, web2py, twisted and so on) and the second one, because you have to, is HTTP POST of Multi-Part FORMs. even with the HTTP Forms, you _still_ don't have to leave the "main" pyjamas (static JS) application page, because the GWT team, bless 'em, came up with a way to do a hidden iframe which does the HTTP POST in the background. _well_ smart cookies, them GWT boys - and we just... lifted it straight into python :) so there's _zero_ further "webuhhh pagizz lohdinn". we found some really smart cookie's jsonrpc server-side code, which turns out to be a stonking JSONRPC service in under 30 lines of code, where you can turn absolutely any python code, pretty much, into an RPC service with one import line, one line of code and then one decorator per function you want to be in the JSON RPC service. this approach, on its own, drastically simplifies python web service development. now your entire server-side web service is implemented in terms of *data* _not_ the presentation-of-the-data-mixed-in-with- the-data-and-oops-er-maybe-a-little-bit-of-javascript-oh-hell-actually- it's-a-lot-of-javascript-and-oh-god-here-we-go-again-how-do-we-debug- this? the only down-side of this approach _would_ be that you'd now have to do everything as a JSONRPC client, which if you were in "pure javascript land" would truly be absolute hell on earth. _but_... as we're talking python... ta-daaa! easy :) ok, not _entirely_ easy, because it has to be done asynchronously. make the call, then wait for a response, timeout or a server error - but, guess what? you can create a python class with functions "onResponse", "onError" and "onTimeout" which will be called when the function has completed (or not) on the server. ta-daaa :) running example: http://pyjs.org/examples/jsonrpc/output/JSONRPCExample.html pyjamas client-side code: http://pyjs.org/examples/jsonrpc/JSONRPCExample.py so - pyjamas developers _don't_ have the same "juggling" problems that the "average" advanced AJAX + web-service programmer has, because everything's compartmentalised along MVC lines: http://www.advogato.org/article/993.html i would say that GWT developers don't have the same problems, but because java is a strongly-typed language, they have a biatch-and-a- half god-awful time carrying out type-casting of JSONRPC parameters and the function return type when it comes back from the server, _even_ though the target language of the compiler is dynamic - javascript! poor things. haw, haw :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 5:57 pm, rantingrick wrote: > On Jun 14, 11:17 am, Stephen Hansen wrote: > > > And the recursive flow of the DOM is powerful > > This style of speaking reminds me of our former hillbilly president > (no not Clinton, he was the eloquent hillbilly!) the one with an IQ of 185? > No i am referring to > good old "George Dubya". the one with an IQ of 190? > He left us with so many juicy sound bites > > HOST: I’m curious, have you ever googled anybody? Do you use Google? > BUSH: Occasionally. One of the things I’ve used on the Google is to > pull up maps. It’s very interesting to see — I’ve forgot the name of > the program — but you get the satellite, and you can — like, I kinda > like to look at the ranch. It remind me of where I wanna be sometimes. o, you must mean sonny-boy, the one with the IQ of 85 due to having destroyed his mind with drink and drugs - ahh, yehhs. the only thing i can respect that man for is the fact that he insists on going to bed before 9:30pm. yeessh, how did america manage to vote in a president who *started out* so blatantly unintelligent, as opposed to voting one in who had an off-the-charts IQ and lost it to alzheimers, dear-old ronnie-boy?? l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 14, 4:17 pm, Stephen Hansen wrote: > >> Did you just call DOM manipulation simple with a straight face? I don't > >> think I've ever seen that before. > > > *lol* - wait for it: see below. summary: once you start using high- > > level widgets: yes. without such, yeah you're damn right. > > See, the thing is, my background is a little bit mixed. ahh? good. perfect. > I've produced > complex yet approachable and dynamic interfaces for both traditional > client applications, and similar level user interfaces for the web. In > the latter case, I don't do HTML/CSS programming anymore as you describe > it, definitely not as "i" would describe it, either! so let's substitute "the average web programmer" for the word "you". > but JavaScript-based building out of the application. yes. that's effectively what pyjs applications are about: as much HTML/CSS as you can stand, then _absolute_ pure javascript from there- on in... only using a compiler (python-to-javascript) so as not to go completely insane - and, from the rest of your message, i _know_ you know what i'm talking about, there :) > And the recursive flow of the DOM is powerful (and in some cases, > superbly suited to a task), but I maintain fully: at no point is it > easy, simple, or even entirely comprehensible to most average geeks. correct. i don't pretend to get it, completely. i tend to put my trust in the pyjamas widgets - things with names like "Grid, FlexTable, Button, HorizontalPanel and VerticalSlider" - and hope for the best. to be absolutely honest, i very rarely even write my own widgets: i advocate that people, myself _especially_ myself included, perform literal line-for-line translations of GWT widgets from java to python. why? because, again: on the basis that google have tons of money to put into GWT widgets, doing full regression tests, and have thousands of users, they can afford to get the widget right across all the browsers. ergo, why duplicate that effort - just code-translate it verbatim! oh, btw, that's turning into quite a powerful project on its own: the goal is to have a fully automated java-to-python translator! http://github.com/thoka/java2python > Traditional GUI models vs the web layout model are just alien to one > another, and the latter is -extremely- convoluted. we've found that there's a third "hybrid" case, and it's hinted at through RIA javascript libraries such as extjs: a traditional GUI model *implemented* as a web app. so those RIA JS libraries are not "vs", they're _both_. except... javascript has its own headaches, so that's why both pyjamas and GWT remove _those_ headaches, by using language translators. so, yah - except when hybridly-hidden behind "widgets", of which pyjamas has something like... 70, and GWT must have 150+ and upwards, if you include 3rd party libraries out there that i can't even begin to count. > The virtue of the web model is that it is very easy to get "Something" > out which looks and behaves almost like what you expect or want with > minimal fuss. > > Then you try to tweak it to get it exactly how you want, and suddenly it > can devour your soul in a hysterical haze of element style interactions > along the DOM. And just when you think you have it: somehow the entire > thing collapses and nothing works. :P tell me about it ha ha - been there :) > Eventually you start to -understand- the DOM, and thinking in DOM, and > you're clinically a little bit insane, but suddenly it all sort of makes > sense. > > I think you've gone down this path and are slightly lost to the dark > forces of the DOM and are no longer seeing that its nutty, cuz > internally nutty is now natural :) no, you'll be relieved to know that, as above, i entirely avoid it unless absolutely necessary (by cheating, and using the java2python approach). i wrote a slider class (veeery basic). ok, i'm lying somewhat: after doing almost 40,000 lines of java to python translation involving heavy amounts of DOM you can't _help_ but begin, by a process of osmosis, to get to grips with it :) > I can usually do real-life interfaces > in traditional GUI models which are far simpler and use less code then > equivalent DOM based interfaces, /except/ in cases where I have a > content flow situation. Where large amounts of 'unknown' are inserted > into an interface and I want everything to go with it well. i think i know what you're referring to: obtaining 700+ bits of data and trying to insert them all at once into the DOM interface, as the web engine is single-threaded, you lock up the browser. and there's no escape! in these circumstances, the trick recommended is to use a timer, breaking up the loop and adding bits at a time. e.g.: http://pyjs.org/book/Chapter.py you can see in onTimer, a simple loop, reads up to 10 lines, fires the timer again. i would _hate_ to have to do this sort of thing in pure javascript. > That's not to say I think you're actually crazy. I just th
Re: Will and Abe's "Guide to Pyjamas"
On Jun 14, 3:53 pm, lkcl wrote: > this is getting sufficiently ridiculous, i thought it best to > summarise the discussions of the past few days, from the perspective > of four-year-olds: not, of course, to imply in _any way_, that anyone but myself on comp.lang.python is juvenile and/or delinquent, and not of course, to imply that any four-year-old is in any way juvenile and/or delinquent. bring on the political correctness... l. -- http://mail.python.org/mailman/listinfo/python-list
Will and Abe's "Guide to Pyjamas"
> oh look - there's a common theme, there: "web technology equals > useless" :) this is getting sufficiently ridiculous, i thought it best to summarise the discussions of the past few days, from the perspective of four-year-olds: http://pyjs.org/will_and_abe_guide_to_pyjamas.html l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 13, 2:34 pm, Stephen Hansen wrote:
> On 6/13/10 4:29 AM, lkcl wrote:
>
> > it's in fact how the entire pyjamas UI widget set is created, by
> > doing nothing more than direct manipulation of bits of DOM and direct
> > manipulation of the style properties. really really simple.
>
> Did you just call DOM manipulation simple with a straight face? I don't
> think I've ever seen that before.
*lol* - wait for it: see below. summary: once you start using high-
level widgets: yes. without such, yeah you're damn right.
> HTML+CSS have some very strong advantages. Simplicity is not one of
> them. Precision web design these days is a dark art. (Go center an image
> vertically and horizontally in an arbitrary sized field!)
stephen, _thank_ you - that was _exactly_ why i decided i flat-out
was NEVER going to do "plain" HTML/CSS programming _ever_ again. i
spent twwoo weeks trying to do exactly this (well, it was 7
boxes, not an image) - and i failed.
i succeeded on firefox to get the boxes centred, but with IE, when
you resized the screen, the bloody boxes went off the top! they were
so "centred" that they went off the top of the screen! and the bloody
idiotic IE team forgot that you can't scroll _up_ off the top of the
screen :)
in desperation, i blindly wandered into pyjamas, and went "ye" -
and within 50 minutes i had converted my site to do exactly this.
you can see the results here: http://lkcl.net and the main code is
here:
http://lkcl.net/site_code/index.py
the relevant (crucial) function is the onWindowResized function which
gets called because of this: Window.addWindowResizeListener(self)
def onWindowResized(self, width, height):
self.toprow.removeFromParent()
self.middlerow.removeFromParent()
self.bottomrow.removeFromParent()
self.html.removeFromParent()
self.ads.removeFromParent()
self.create_layout()
the create_layout function basically does this:
width = Window.getClientWidth()
if width > 800:
toprow = HorizontalPanel()
middlerow = HorizontalPanel()
bottomrow = HorizontalPanel()
elif width > 640:
# different types of layout panels
else:
# utterly skinny vertical-only panels
those three panels are added into another panel which has 100% width
and 100% height, and has "centre" properties attached to its cells;
voila, the boxes always sit in the middle of the screen. when the
screen is too big for the 100% height outer panel, the boxes "push"
against the constraints of their outer panel, thus forcing the screen
to become bigger and thus automatically a vertical scroll-bar is
added. for some browsers this results in another onWindowResize
notification and for some it doesn't (eurgh) - but that's another
story :)
this is what i was referring to in another message... rats, can't
find it now: it was the one asking about why qt4 and gtk2 layouts
don't cut it, and i explained about the recursive complex child-parent
interaction rules between DOM objects.
but - allow me to write a quick app which does what you ask:
from pyjamas.ui.Image import Image
from pyjamaas.ui.AbsolutePanel import AbsolutePanel
from pyjamaas.ui import RootPanel
from pyjamas import Window
class Thingy:
def __init__(self):
self.panel = AbsolutePanel(Width="100%", Height="100%")
self.image = Image("http://python.org/python.png";)
self.panel.add(image, 0, 0) # add in top-left just for now
# make a "fake" initial window resize notification
self.onWindowResized(Window.getClientWidth(),
Window.getClientHeight())
Window.addResizeListener(self)
def onWindowResized(self, width, height):
""" ok - ignore the image's width and height
because you have to wait for it to load, first,
and that means doing an onImageLoad async notification
and this is supposed to be a short demo!
"""
self.panel.setWidgetPosition(self.image, width/2, height/2)
RootPanel.add(Thingy())
and... yes, honest to god, that's a web application. _really_ a web
application. not an HTML/CSS one, but it's still a web application -
and not a single line of javascript or even DOM manipulation in sight.
if you had to do that as javascript, it would be... eurgh - 300 lines
of unreadable crap? if you had to do that *without the pyjamas ui
widget set* it would be ... ergh... 150 lines of barely tolerable
crap. but with the AbsolutePanel class, and the Image widget, and the
neat "wrapping" of event handling? pffh - complete doddle.
i think... this is what's making pyjamas so hard for people to grasp.
it sits literally in the middle b
pyqt4 vs pygtk2 vs pyjamas (was: GUIs - A Modest Proposal)
On Jun 13, 3:43 pm, Michael Torrie wrote: > On 06/13/2010 05:29 AM, lkcl wrote: > > > really? drat. i could have done with knowing that at the time. > > hmmm, perhaps i will return to the pyqt4 port after all. > > We're now wandering well off-topic here, but then again this thread was > never really on any particular topic. :) > I have to say I'm really confused as to your issues with GTK and Qt. yeahh... it's kinda necessary to have done complex HTML/CSS-based layouts (or better yet, an equivalent, e.g. using declarative python- driven widget-enhanced DOM programming) to appreciate the perspective i'm coming from. the "rules" for table layouts in browsers are (aside from their technical limitations) incredibly powerful, flexible and ultimately very very forgiving of users' lack of knowledge and experience. use of - reliance upon - these rules results in quite a bit less code (both for the pyjamas ui widget developers to have to write, and also for the users/developers of the pyjamas widget set). so my expectations were that i should be able to do the same sort of thing with GTK or QT, and... it just wasn't happening. to highlight this further, i should point out that i looked up paul bonser's browser-written-in-python, called pybrowser: http://git.paulbonser.com/ in it, you can find some pseudo-code for table/div which he's obviously looked up somewhere, presumably in W3C DOM specifications. he's already successfully implemented rules, but the rules he left for another time. i tried implementing them: i cannot make head nor tail of the algorithm/pseudocode :) it's _that_ complex a recursive interaction, between block-based and flowing layout objects. i mention this because to even _remotely_ attempt to accurately re- create pyjamas desktop using Qt4 or Gtk2, it would be necessary, ultimately, to implement the same browser-based recursive layout algorithm that is already in existing web browsers. by doing that, effectively i would actually be creating the vast majority of the functionality of a web browser... in python! and rather than do that from scratch, i would actually be better off either helping (or waiting for) paul to work on pybrowser, or recover and work on grailbrowser (which i've begun doing - it now runs under python 2.4 and just needs all its regular expressions converted from regex to sre in order to run under python2.5+) http://github.com/lkcl/grailbrowser ... ... and then using _that_ as the basis for another pyjamas port, by adding and using W3C DOM functions (which don't exist in grailbrowser sadly). paul bonser's work is actually the better underlying framework: he's already added the W3C DOM TR1 through to TR3 properties and functions, such as getElementById(), appendChild(), offsetWidth and so on, but grailbrowser is the better _actual_ browser on account of it actually... working! :) in a delicious piece of irony, which brings us back full circle to the original discussion, python/tk-haters will howwl with fury to learn that grailbrowser is a fully-functioning 35,000-line python/tk application :) > I've seen and done all kinds of fancy widget layouts in Qt and have > *never* had to subclass layout. If you think you need to subclass > QLayout, most of the time you're doing it wrong. You are familiar with > how the vertical and horizontal layouts and spacers work in Qt, aren't > you? yes. > Sometimes you need a grid for a table or the specialized form > grid. But other than that you want a dynamically-sizing layouts most > of the time. And Qt's Vertical and Horizontal layouts do that. sadly, not to the kind of recursive / child _and_ parent inter- dependent level as browser layouts that would make it a simple viable alternative. > I'm also confused by your claim that GTK lacks the layout widgets you > need as well. GTK has the GtkHBox layout class which acts much like > your tag. Anything to pack in the hbox is automatically layed > out in a dynamicially-resizing way. i did map pyjamas UI HorizontalPanel directly onto GtkHBox, and so on: i got a long long way, very very quickly by doing that. perhaps... perhaps if you have time, if you could take a look at the pyjd-gtk2 and/or the pyjd-qt4 ports, you might be able to point out where i'm going wrong. they're both here: http://github.com/lkcl/pyjamas-desktop they're a bit old, but are functional (install python-gtkhtml2 even to get the pyjd-qt4 port to run, there's some code still accidentally left in) and you run them with "hello_loader.py" by hacking in the appropriate class - you'll see what i mean. > > excellent! that actually makes it worthwhile carrying on. the only > > other thing that needs solving is that RichText is forced to have its &
Re: WebBrowserProgramming [was: GUIs - A Modest Proposal]
On Jun 13, 4:52 pm, a...@pythoncraft.com (Aahz) wrote: > In article , > > lkcl wrote: > > > i'm recording all of these, and any other web browser manipulation > >technology that i've ever encountered, here: > > >http://wiki.python.org/moin/WebBrowserProgramming > > Neat! Why aren't you including Selenium/Windmill? . cos i'd nver not in a miiillion squillion years heard of it. until now. loovelyy. ok. added selenium - now to look up windmill. thanks aahz. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 13, 3:52 pm, Arndt Roger Schneider wrote: > lkcl schrieb: > > > [snip] > > > it's the exact same thing for SVG image file-format. i'm > >_definitely_ not convinced that "SVG the image fileformat" is The One > >True Way to design images - but i'm equally definitely convinced of > >the power of SVG manipulation libraries which allow for the creation > >SVG images using declarative programming. > > You rather severly underestimate the impact from SVG! no - i kept things brief, so as not to dominate the postings here: you've very kindly filled in the blanks, and given far more information than even i was aware of, which is great. > 1. SVG is a complete visualization system and not an fancy way to create > icons. ... all of which is accessible via DOM manipulation, via the W3C-DOM- specified functions through the element. use of which has resulted in the creation of a very powerful _python_ library which re- presents those SVG Canvas functions. fillRect. saveContext. translate. demo of end-result usage can be seen here: http://pyjs.org/examples/gwtcanvas/output/GWTCanvasDemo.html http://pyjs.org/examples/asteroids/output/Space.html > Using HTML/CSS/DOM/javascript for application building: > Well, yes can be done. yes, it could. personally i wouldn't recommend the javascript bit. it's too dreadful. :) > HTML is however text oriented; each > application entirely based on this technology will be saturated > with text. ah - no, it won't. isn't. pyjamas apps are the proof that that isn't the case. pyjamas applications contain, at the absolute basics, _one_ HTML file comprising... about eight lines, the most important two bits being a "meta" tag naming the pre-compiled application, and a "script" tag with bootstrap.js which knows about the aforementioned "meta" tag. that's _it_. the rest can be done _entirely_ using declarative-style programming. but... if you _want_ to, that "loader" file can be a full-blown PHP app: just as long as that meta tag is there, and the bootstrap.js is there, the pyjamas app can be initiated "on top of" the PHP page. just like any other javascript can be run and can begin to manipulate the DOM. so it's just a matter of degree. you can either specify almost everything in "text" HTML/CSS or you can do entire DOM- manipulation or anything in between, to suit _your_ personal preference. i must not be explaining this very well, for which i apologise. > >>or whatever the W3C technology of the month is. > > > :) don't underestimate how much time and money is going into the W3C > >standards! and remember, someone's got to implement them, so the > >actual proof of the pudding is not what the W3C thinks but whether the > >technology ends up actually in the hands of users and is successful > >_for users_. > > > l. > > The mony part is definitly important. Tk is actually a good example for > the working of money-politics (the absence thereof). :) yehhs... and then people complain when it doesn't "look good". interesting neh? hence a reason why i'm advocating to "leverage" the incredible power of the technologies which _have_ had vast amounts of money/effort poured into them, with very little effort spent on the "leveraging" bit. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 13, 9:01 am, Jeremy Sanders wrote: > lkcl wrote: > > * in neither gtk nor qt does there exist an "auto-layout" widget > > that's equivalent to putting some DOM objects into a , > > to "flow" widgets that wrap around. yes, you can put words into a > > Label and get them to flow, but not _widgets_. > > I'm pretty sure in PyQt4 that you can derive your own layout class from > QLayout to get what you want. No C++ is required. You can easily extend PyQt > without using C++. really? drat. i could have done with knowing that at the time. hmmm, perhaps i will return to the pyqt4 port after all. > There is even an example in the PyQt examples which does something similar > to what you want: see examples/layouts/flowlayout.py excellent! that actually makes it worthwhile carrying on. the only other thing that needs solving is that RichText is forced to have its width and height set. but it mayyy be possible to create an appropriate QLayout derivative: i'll have to see. > Personally I find the Qt layout to be much better than anything provided by > CSS and HTML. Personally I'd rather be writing complex C++ templates that > those, though it does give you a feeling of achievement when you get what > you want with CSS. i didn't point this out at the time (and have done so to graham's post, but it's worth reiterating briefly here): remember that you're not _entirely_ stuck with "CSS the file-format" - you _can_ do declarative DOM manipulation (from python): self.element.style.backgroundColor = "#ffcc00" that's python _not_ javascript :) so, now you can create **kwargs jobbies, you can store properties in xml fileformats, read them and then "apply" them using **kwargs to the stylesheets; you can create functions which set multiple CSS properties at once, based on some calculations and so on. so, yah - when you're "stuck" with "just CSS the fileformat", it's a complete dog. joy. lovely. you can set the width and the background. wow, big deal. but when you start combining it with python, you've opened up a completely new dimension. it's in fact how the entire pyjamas UI widget set is created, by doing nothing more than direct manipulation of bits of DOM and direct manipulation of the style properties. really really simple. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 13, 3:34 am, Gregory Ewing wrote: > lkcl wrote: > > * in neither gtk nor qt does there exist an "auto-layout" widget > > that's equivalent to putting some DOM objects into a , > > to "flow" widgets that wrap around. > > You essentially seem to be complaining here that pqyqt and > pygtk are not HTML. no, i'm not complaining - i'm pointing out that in my meandering experiences to pick suitable technology, i found, very simply, that both pyqt and pygtk didn't cut it. that's not a "complaint". so i'm stating/implying that from the experience that i had with both toolkits, pyqt and pygtk were not as easy to create layouts or widgets with (but caveat: jeremy kindly points out that in pyqt there is examples/layouts/flowlayout.py) another way to put that: i'm stating that, in my search for suitable technology to implement W3C-standards-like behaviour, such that i could map an existing widget set API on top of it, i found both pygtk and pyqt4's "bang per buck" as far as both extensibility and existing functionality was concerned to be below an acceptable threshold *for me*. statement of "personal experience". not "complaint". > They have their own auto-layout mechanisms > that do what they're designed to do well enough -- they just > happen to be based on a different model from HTML. one which turns out to be sufficiently different from HTML as to make it beyond my time and patience to implement one in terms of the other. again - that's not a "complaint", just a statement that i prefer to leverage technologies where the "bang per buck" or better "bang per line-of-code" is way above average. > I'm far from convinced that HTML and CSS are the One True Way > to design GUIs these days, if you have "HTML the fileformat" and "CSS the fileformat" in mind when saying that, i can tell you right now that they're not. fortunately, with the W3C DOM functions exposing properties and style attributes, it's possible to manipulate the exact same attributes that CSS and HTML "files" provide access to, using a declarative programming style. so with pyjamas you get the best of both worlds. (and i've found that the combination of the advanced features of python, and declarative DOM manipulation, is _definitely_ worthwhile exploring, and i definitely find it to be far more powerful than pyqt4 or pygtk programming). it's the exact same thing for SVG image file-format. i'm _definitely_ not convinced that "SVG the image fileformat" is The One True Way to design images - but i'm equally definitely convinced of the power of SVG manipulation libraries which allow for the creation SVG images using declarative programming. but, all that having been said, and returning to "HTML and CSS (the fileformats)", there's a lot to be said for convincing people who are stuck in those worlds of the benefits and freedom of declarative programming... _without_ having to get involved directly in javascript. > that web apps are about to take over > the world, etc. There is still a place for GUI toolkits that > are not based on the DOM, that there definitely are. > or whatever the W3C technology of the month is. :) don't underestimate how much time and money is going into the W3C standards! and remember, someone's got to implement them, so the actual proof of the pudding is not what the W3C thinks but whether the technology ends up actually in the hands of users and is successful _for users_. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 12, 7:29 pm, Terry Reedy wrote: > On 6/12/2010 9:26 AM, lkcl wrote: > > > [ye gods, i think this is the largest thread i've ever seen, > > For python-list, it is possibly the longest this year, but definitely > not of all time ;-) oh dearie me... > > yep. that's why i ported pyjamas, which was a web-only/browser-only > > UI toolkit, to the desktop. it's a _real_ eye-opener to try to use > > the "failed" ports of pyjamas to both pygtk2 and pyqt4, which you can > > still get athttp://github.com/lkcl/pyjamas-desktop- see pyjd-pyqt4 > > and pyjd-pygtk2 > > > these failed ports give you the clearest and bluntest indication of > > the failings of pyqt4 and pygtk2. after using those two "top" > > mainstream python GUI widget sets, i didn't try any others. > > Can you expand on this? In brief, What were the 'failings' and were they > failings of the wrappers or the underlying toolkits? the toolkits themselves. it's related to layout, to presentation, but most of all to the implementation of the most basic widget - Label! i actually got quite a long way with the qt4 port, after deciding to deal with Label some other time, but then... ok, best to read on :) * in neither gtk nor qt does there exist an "auto-layout" widget that's equivalent to putting some DOM objects into a , to "flow" widgets that wrap around. yes, you can put words into a Label and get them to flow, but not _widgets_. * in neither gtk nor qt is HTML properly supported. qt has a "RichText" widget but it's drastically limited. * if in gtk you use PyGTKHTML2 you cannot expect it to take care of its own width and height: you *have* to set width and height, whereupon it immediately defeats the container's layout rules. (and i just was not prepared to do "onresize" notification throughout the entiiire UI wrapper toolkit, explicitly implementing W3C DOM rules in terms of gtk or qt widgets, examining the size of the HTML text after it had been drawn once, then... gaah. _no_.) * GTKHTML3 does have "flow" capability, and even allows you to attach widgets to the layout based on the "id" associated with bits of HTML... but PyGTKHTML3 was dropped because webkit came along, and everyone loved that so much they abandoned work on making python wrappers to GTKHTML3. * qt4 "RichText" _also_ fails to set width and height correctly and requires explicit width and height setting, in pixels, which _again_ defeats container layout rules. * in implementing a Pyjamas Grid widget using qt4, qt4's Grid widget turned out to have a bug where the Layout Container classes could only be added once. you're _supposed_ to be able to remove the widgets and the Layout Containers and be able to re-add and re-lay-out the Grid, but this failed miserably: the widgets _remained_ in-place and were drawn _twice_. whoops. * developing containers for both gtk and qt4 (one idea suggested to solve some of the above problems) requires writing c code, and adoption of the resultant containers by the respective communities. i scratched that idea as unworkable. * both gtk and qt4 can use webkit to display HTML. all i ing wanted was a Label widget to display a word or a sentence, not an entire whopping 12mb library with a runtime overhead of 6mb per widget! so the use of pywebkitqt or pywebkitgtk _just_ to implement pyjamas.ui.Label was absolutely out of the question. * there's no way you can apply CSS stylesheets to gtk or qt4 (and Qt4's RichText certainly doesn't support CSS). one developer i spoke to at the time was working on exactly this, for gtk, but it was an "afterthought" - and more of a GTK "theme". you certainly weren't going to be able to add a CSS style on a per-id basis: only to "classes" of widgets (Buttons etc.) the second thing i had to consider was: how the hell am i going to implement the embedded object tag, using gtk or qt4? although it _is_ possible to put ... ohh... what is it... you can embed ... something, i can't remember what it is, but there's a way to put SWF into gtk apps... well, i realised i was looking at this entirely the wrong way. and that was the point at which i went, well wtf am i doing considering shoe-horning a square peg into a round hole for, when i can just use webkit with glib/gobject bindings and then python bindings on top of that, or xulrunner with python-xpcom for that matter, and dropped both gtk and qt4 like scalding hot coals and made a beeline for webkit's source code. hulahop, the missing piece of the "xulrunner" puzzle, turned up a few months later; once the dust had settled from those, MSHTML actually turned out to be a breeze. so i apologise if you were expecting a short answer, but
Re: WebBrowserProgramming [was: GUIs - A Modest Proposal]
On Jun 12, 6:14 pm, Stephen Hansen wrote: > On 6/12/10 9:20 AM, lkcl wrote: > > > there are _lots_ other options that i know of. here are three of the > > best: > > [list of browser engines cut for brevity] > > Although I didn't state it or even hint at it, I thought it was implied > and obvious-- though obviously I was wrong ;-) Oops! i just wanted to do a "completeness" thing. apologies, there. -- http://mail.python.org/mailman/listinfo/python-list
Re: safer ctype? (was GUIs - A modest Proposal)
On Jun 12, 6:05 pm, Stephen Hansen wrote: > On 6/12/10 9:55 AM, lkcl wrote: > > > On Jun 12, 8:11 am, "Martin v. Loewis" wrote: > >> Notice that it's not (only) the functions itself, but also the > >> parameters. It's absolutely easy to crash Python by calling a function > >> through ctypes that expects a pointer, and you pass an integer. The > >> machine code will dereference the pointer (trusting that it actually is > >> one), and crash. > > > what's so bad about that? (this is a genuine, non-hostile, non- > > rhetorical, non-sarcastic question). > > > (if the answer is "because you can't catch a segfault as a python > > exception", then the question is repeated) > > ... ?! > > Its not OK for code written in Python to cause a segfault; its not OK [i knew this would be the / an / something-like-the answer, but i'm just... "reading the script" so to speak] > Its one of the reasons why we *like* Python at my day job. (Though it > applies to nearly any other high level language): its inherently safer. > A programming goof, oversight or unexpected event causes an exception. > It doesn't cause a buffer overflow. ok... analogy: when using g++ to compile c++ code, would you place use of "asm" statements into the same sort of foot-shooting category? > P.S. Yes, I do understand that ctypes invalidates those assumptions. And > that's OK. Every once in awhile, with great care and research to make > sure I know what I'm doing, I'll take the risk anyways. I do understand > the policy in terms of the stdlib though. I just wish it didn't apply to > win32 API's somehow. No, I know its not at all logical. Leave me alone. :) teehee :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python ctypes / pywin32 [was: GUIs - A Modest Proposal]
On Jun 12, 5:56 pm, Robert Kern wrote: > > just because a library has a means for programmers to shoot > > themselves in the foot doesn't mean that the programming language > > should come with kevlar-reinforced bullet-proof vests. > > That's exactly why it's *in* the standard library, but also exactly why it > won't > be *used by* other parts of the standard library. If it's used by other parts > of > the standard library, then it won't be the case that only the sanest and most > careful of programmers are going to use it. ack. understood. thank you. > > removal of ctypes would be a big, big mistake. i trust that i have > > misinterpreted the implication of what you're saying, martin. > > Yes. ok whew :) -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 12, 3:07 pm, Kevin Walzer wrote: > On 6/12/10 9:44 AM, lkcl wrote: > > > that's not quite true - you can create a simple core which is easily > > extensible with third party contributions to create more comprehensive > > widgets. > > That's exactly the design philosophy of Tk: a small core widget set > (recently expanded somewhat with the ttk widgets) and an API that is > easily extensible, either at the script level (megawidgets, cf. using an > entry widget and a listbox to build a combobox) or at the C level (more > complex, but hardly impossible). thank you for pointing this out, kevin. learned a lot today, just from reading this one thread. about msg no 170 was where mention of tk libraries for opengl, and various other types of highly sophisticated widgets were mentioned. personally i think that these third party comprehensive extras alone make the answer to "should there be a replacement for python-tcl/tk" a resounding "no" but then i don't really need to say that - we kinda know the answer's "no" anyway :) > I've used a browser-based app before (Adobe AIR app running in IE) and > while it wasn't horrible, I certainly did not prefer it to a native > desktop app: I got sick of waiting for the app to reload because of a > slow network connection. yeahh, adobe AIR is basically webkit. not entirely sure what else they did with it - extended it to include their much-abused version of ecmascript (aka actionscript). never really been that interested in it, being a pythonist myself :) i think there's something about flash/AIR apps that just grates against the nerves. it doesn't really matter what reasons people come up with - it just feels... "wrong". that's not to say, however, based on that _one_ leveraging of browser- based web-app technology, that _all_ browser-based web-app technology falls into the same "feels wrong" bucket. coming back to pyjamas (again - sorry!) as an example: http://bit.ly/9xZ3MZ take a look at maxima's reply: you can clearly see that he's nuts about pyjd, and finds it to be slightly scarily wonderful for GUI development. perhaps it's because it's pythan, and free software- based, not adobe-driven, i don't know. *shrug* :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: safer ctype? (was GUIs - A modest Proposal)
On Jun 12, 8:11 am, "Martin v. Loewis" wrote: > > Got me thinking, is it perhaps doable to have a 'safe' ctype that is > > guaranteed to be in the stdlib? Perhaps crippling it in a sense that it > > only allows a known set of functions to be called? > > In some sense, a C module wrapping a selected number of functions > (like the win32 extensions) is exactly that. > > Notice that it's not (only) the functions itself, but also the > parameters. It's absolutely easy to crash Python by calling a function > through ctypes that expects a pointer, and you pass an integer. The > machine code will dereference the pointer (trusting that it actually is > one), and crash. what's so bad about that? (this is a genuine, non-hostile, non- rhetorical, non-sarcastic question). (if the answer is "because you can't catch a segfault as a python exception", then the question is repeated) l. -- http://mail.python.org/mailman/listinfo/python-list
WebBrowserProgramming [was: GUIs - A Modest Proposal]
On Jun 10, 6:56 pm, Stephen Hansen wrote: > For example: if you want to embed a CSS-capable web-browser into your > app? PyQT is actually your best option-- albeit a commercial one if > you're not open source.. wx/Python haven't yet finished WebKit > integration(*). there are _lots_ other options that i know of. here are three of the best: * python-comtypes and wrap an IWebBrowser2 instance (out of MSHTML) - you can get a win32 GDI "handle" id out of this: if you know what you're doing, you could likely embed that into a gtk or qt app, just in the same way as you can embed X11 "windows" into pygtk apps, by knowing the X11 window "handle" id. * python-xpcom and python-hulahop on top of xulrunner. hulahop is the python "magic glue" between GTK and the XPCOM "access" interface to the xulrunner web engine. hulahop allows the xulrunner engine to be embedded as a python gtk "widget", whilst also giving you a handle to the xpcom interface. * pywebkitgtk - in its current released/stable form, it gives you juuust enough to embed a web browser, but you can't actually get access to any of the DOM functions (unlike hulahop/xpcom and comtypes/ MSHTML). i'm recording all of these, and any other web browser manipulation technology that i've ever encountered, here: http://wiki.python.org/moin/WebBrowserProgramming l. -- http://mail.python.org/mailman/listinfo/python-list
Python ctypes / pywin32 [was: GUIs - A Modest Proposal]
On Jun 10, 6:26 pm, "Martin v. Loewis" wrote: > >> or PyGui would need to be implemented in terms of ctypes (which then > >> would prevent its inclusion, because there is a policy that ctypes > >> must not be used in the standard library). > > > Is there? I wasn't aware of that. What's the reason? > > ctypes is inherently unsafe. that's ok. only the sanest and most careful of programmers are going to use it. and all they're going to do is crash their application if they get it wrong. or, on an OS which is _known_ to be so unstable that it will fall over with the slightest provocation, crash the OS and require a press of that little button which was moved to the front _just_ to deal with that OS's instability, once again. just because a library has a means for programmers to shoot themselves in the foot doesn't mean that the programming language should come with kevlar-reinforced bullet-proof vests. > It must be possible to remove it > from a Python installation, as long as that's not an official policy statement that ctypes will, at some point in the future, be removed from python, i'm happy. the last thing i want to have to do is to have to include and maintain, as part of the pyjamas download, a complex python-ctypes library in order to get at the win32 functions "CreateWindowEx"; the second last thing i want to have to do is rewrite pyjd's MSHTML port; the third last thing i want to have to do is state that a 2nd and _much_ larger library dependency/download is required: pywin32. one of the really nice things about having chosen ctypes and a copy of henk punkt's windows.py file is that the only dependency required is one single 350k download: python-ctypes. last time i looked, pywin32 was a whopping 6mb, and there's _nothing_ in pywin32 that pyjd actually needs. i deliberately bypassed python-win32com for exactly the same reason: it turns out that direct ctypes access to Variant and all other OLE / COM types is perfectly sufficient. removal of ctypes would be a big, big mistake. i trust that i have misinterpreted the implication of what you're saying, martin. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
> That's the reason why it won't happen. Everybody asking for change is > not willing to lead the effort. Everybody who would be able and might be > willing to lead the change fails to see the need for change. *lol*. i don't know why, but i think that's so hilarious i might make it my .sig. it must be because it's so beautifully zen and circular. there are foools who aren't confident and know it; there are foools who _are_ confident, and experienced enough to not try it. that just leaves the foools who are confident enough to try it, but whom nobody will follow :) it's a bloody wonder anything gets achieved at all in free software ha ha :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 9, 5:38 pm, rantingrick wrote: > Yes we need a leader. Someone who is not afraid of the naysayers. > Someone with Guido's vision. When the leader emerges, the people will > rally. ... Mahh? Whey'rus ma guuhhn? haww haww :) -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 9, 5:16 pm, Ethan Furman wrote: > Gregory Ewing wrote: > > Kevin Walzer wrote: > >> PyGUI ... certainly is *not* a lightweight GUI toolkit that could > >> easily be incorporated into the Python core library--it instead has > >> rather complex dependencies on both other GUI toolkits and Python > >> wrappers of those toolkits. > > > I don't see how the dependencies could be regarded as "complex". > > There's more or less only one on each platform, and they're > > pretty standard accessories for the platform concerned. You could > > say there are two on Linux if you count gtk itself, but you almost > > certainly already have it these days if you're running any > > kind of desktop at all. > > *Alert* Potentially dumb question following: On the MS Windows > platform, Gtk is not required, just win32? by using python-comtypes and python-ctypes, you can pretty much control absolutely anything that's installed, and access just about anything: any win32 dll, any function. some of the function parameters you might have to guess, but it's doable. in this way you can actually access the win32 GDI (graphics driver interface) which is a serrriously low-level GUI toolkit built-in to the win32 API, and can implement much higher-level APIs on top of it. GDI is somewhat at the level of the X11 protocol. as it's so low-level, the number of applications which actually do this is _extremely_ small. the only reason i got involved at all was to do the bsolute minimum amount of work required to embed _one_ single object instance into a GDI window, taking up the entire width and height: an IWebBrowser2 OCX control, lifted straight out of MSHTML.DLL. you can look at what i did, here: http://pyjamas.git.sourceforge.net/git/gitweb.cgi?p=pyjamas/pyjamas;a=tree;f=pyjd;hb=master see windows.py and pyjd.py. windows.py is lifted straight out of a library by henk punkt; pyjd.py is a mish-mash amalgam of various bits of code i found by googling for 3 weeks solid on variations of "python MSHTML IWebBrowser2" and so on. much of the work that i found i had to go back _years_, to older versions of python and older python libraries that have long since been retired because nobody bothered with the techniques that were offered. so, yah. thanks to henk punkt's little windows.py module, it's possible to "appear" to have direct access to win32 functions such as "CreateWindowEx", and thanks to python-comtypes it's possible to get access to the COM interface of DLLs and then you're off (in this case, with the fairies). l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 9, 11:16 am, ant wrote: > And who are the beginning programmers going to turn into? If we do our > stuff right, Python programmers. If not, > Java or PHP or Visual Basic programmers. Or website designers. Or > worse (is there a worse?). yes - Java programmers who use COM under Win32 to connect to a OCX browser plugin written in Visual Basic, in a website written in PHP. no - wait: Java programmers who use COM under Win32 to connect to a Silverlight .NET application written in Visual Basic, in a website written in PHP. yeeehawww. got all the god-awful trite crap which has driven people nuts for years, and into the welcoming and consoling arms of the python community, alll into one gory sentence. :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 9, 8:45 am, Lie Ryan wrote: > On 06/09/10 08:20, Martin P. Hellwig wrote: > > I do think it is technically possible to have your own window manager in > > python on x11 but I have no idea if you have equal possibilities on mac > > Doesn't Mac uses an X server as well? not by default, no. you have to install it (from the XCode bundle/ package). l. p.s. i skipped replying to the other message but yes there is actually an implementation of x11 directly in pure python. you can use it to write window managers in it. but it's _not_ an x11 server implementation, it's just equivalent to... ooo... probably libx11: i.e. it connects to e.g. KDE, GDM, Fvwm and sends and responds to events. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 9, 5:12 am, rantingrick wrote: > But you know i think it boils down to fear really. He is comfortable > in his life and wishes to keep it as cookie cutter as he can. Any > outside influence must be quashed before these meddling forces can > take hold of him. He is so fearful of seeing the light in an opposing > argument that blinding himself from reality is easier than facing > reality. a very wise person told me a phrase which he'd heard, and i believe it's relevant and hope you won't mind me quoting it: "stress is where the mind compares the internal world with the external, cannot cope with the discrepancy, and places blame on the *external* world". there's food for thought in that, for all concerned. nobody's actions, here, are "wrong", they just "are". l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 7, 9:25 pm, Arndt Roger Schneider wrote: > Terry Reedy schrieb: > Forget postscript! > Generate SVG from a tk canvas or --better-- from tkpath. > Jeszra (from me) generates SVG. There is also a SVG export ... orr, you use a modern web browser engine such as XulRunner 1.9 (the engine behind FF 3+), or webkit (the engine behind arora, midori, safari, android, chrome, palm's webos, adobe AIR, iphone, ipad, appcelerator, nokia S60 browser, the IE chrome plugin, blackberry 4 OS's web browser, and god knows what else). and you create python bindings to that modern web browser engine, and you can then use DOM manipulation (like javascript, only in python) to get at those SVG functions, and much much more. ... how does that sound? > Will any big GUI-Framework work on those devises? > > No! yes. called a web browser. most likely a modern webkit-based engine. > Will SVG run on thoses devices? yes. in the webkit-based web browser. or the "opera mini" browser. etc. etc. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 6, 10:55 pm, ant wrote: > On Jun 6, 2:22 pm, ant wrote:> I get the strong feeling > that nobody is really happy with the state of > > Python GUIs. > > > > What an interesting set of responses I got! > And - even more interesting - how few of them actually seem to think > there is a problem, let > alone make any attempt to move the situation forward. > I appreciate that there are proponents of many different GUIs. I am > asking that all step back > from their particular interests and - for example - try to see the > situation from the viewpoint of > - say - a Python newbie, or an organisation that is thinking of > switching from (example only!) Visual Basic. > > I obviously didn't make my main point clearly enough; I'll restate it > with a different emphasis: > The default GUI shipped with Python is Tkinter. > Few people seem to like it much. This has several consequences. > - It has not blossomed, like Python has. > - There are not hundreds of talented programmers making rapid and > impressive improvements to it. > - Books about Python use it in examples (because it IS the default), > but imply that one should move on. > > The result that our hypothetical new recruit has to make a choice for > the new, big project. Remember that > GUIs have hundreds (sometimes thousands) of classes, functions and > constants. Let alone idioms and design > patterns. That is what I meant by 'Our resources are being > dissipated'; the effort of learning, remembering > and relearning a workable subset of these is substantial. > So it would be good to be able to use One Right Way, not try several > (as I have - I will admit I didn't try PyQt; > GUI fatigue was setting in by then). > > If we are to make progress, I can see two obvious approaches: > 1) Improve Tkinter to the point where it is supportable and supported > by a good fraction of Python programmers > or > 2) Drop Tkinter as the default and use something else. > > If we choose 2) then we have a new set of possibilities: > 2a) Use one of the 'major' GUIs, pretty much as is, but presumably > with a lot more people supporting it if it is the default. > 2b) Use one of the 'minor' GUIs, and get a lot of people working on it > to make it really good. > 2c) Start from scratch. With a project supported by the Community as a > whole, with the agreed objective of being the default. > > None of these is easy. All require strong leadership and great > committment. > > What surprises me is the apparent willingness of the Python community > to let this issue slide. ah - i think... i believe you may be confusing realism with fatalism. experienced python developers are also experienced, specialist c programmers (amongst other things) and experienced software engineers. they've been around a while (10+ years). they _know_ how much effort is involved in creating a major project such as a GUI widget set (and you can get a wildly-wrong but nevertheless useful answer from ohloh.net statistics, by going to http://ohloh.net/p/gtk for example) so, spec'ing it out, we _know_ that to create a decent GUI widget set, from scratch, in c (to make it fast enough) would be... ye gods... 50 man-years of effort, minimum? you _might_ be able to reduce that by using somebody else's library (libcairo, libpango) but... just... _why_?? so this was why i went "f*** that!" and "leveraged" web browser technology, jumping from virtually nothing (an abandoned python-to- javascript compiler project) to a world-class GUI toolkit, in under 18 months of _part time_ effort. > My concern is simple: I think that Python is doomed to remain a minor > language unless we crack this problem. ah. take a look at that chart that keeps cropping up every now and then: python is _not_ a minor programming language. most likely due to django, it's rated about 7th with about ... i think it was 6% share. perl is now _under_ 4%! so i don't believe there are any concerns there: python has enough alternate uses other than as a GUI toolkit to keep it going :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
On Jun 6, 10:49 pm, Kevin Walzer wrote: > > - Pythonic > > - The default GUI (so it replaces Tkinter) > > - It has the support of the majority of the Python community > > - Simple and obvious to use for simple things > > - Comprehensive, for complicated things > > - Cross-platform > > - Looks good (to be defined) > > - As small as possible in its default form > > These goals are not all complementary. In fact, some of them, such as > "small" and "comprehensive," are mutually exclusive. that's not quite true - you can create a simple core which is easily extensible with third party contributions to create more comprehensive widgets. in the GWT arena, you have gwt-g3d, gwt-incubator, gwt-gchart and so on, all of which were created very easily thanks to the power of the underlying GWT core codebase, _none_ of which are actually included into GWT by default, _all_ of which can be installed by users and simply "imported" just like the core. now s/GWT/pyjamas and you have the exact same thing, and all the satisfiable requirements are met. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUIs - A Modest Proposal
[ye gods, i think this is the largest thread i've ever seen, but i still feel compelled to wind back to the beginning and spew forth words.] On Jun 6, 2:22 am, ant wrote: > I get the strong feeling that nobody is really happy with the state of > Python GUIs. yep. that's why i ported pyjamas, which was a web-only/browser-only UI toolkit, to the desktop. it's a _real_ eye-opener to try to use the "failed" ports of pyjamas to both pygtk2 and pyqt4, which you can still get at http://github.com/lkcl/pyjamas-desktop - see pyjd-pyqt4 and pyjd-pygtk2 these failed ports give you the clearest and bluntest indication of the failings of pyqt4 and pygtk2. after using those two "top" mainstream python GUI widget sets, i didn't try any others. > Whether or not we like graphics programming, it's not going to go > away. no you're right, it's not. ... but as web browser technology development continues to accelerate, the top mainstream GUI technology (not just python GUI technology) is going to look more and more archaic in comparison. > I ask the group; should we try to create a new GUI for Python, with > the following > properties?: > > - Pythonic > - The default GUI (so it replaces Tkinter) > - It has the support of the majority of the Python community > - Simple and obvious to use for simple things > - Comprehensive, for complicated things > - Cross-platform > - Looks good (to be defined) > - As small as possible in its default form i invite anyone considering starting a new python GUI project to consider these questions: * how much effort has been and is being spent, right now, on developing and debugging each of the python GUI widget sets, as compared to the efforts on web browser technology (MSHTML, KHTML ok maybe not kHTML, WebKit, XulRunner)? (put another way: how long have web browsers existed and how much user-market-share do web browsers have, compared to GUI and python GUI widget sets?) * are python GUI widget sets easy to compile cross-platform, as compared to web browser technology which is _definitely_ cross- platform? * how easy is it to extend the existing python GUI widget sets with "new" or "custom" widgets, as compared to web browser technology where you can manipulate bits of DOM? if you're not sure of how simple/ complex each task is, read and compare these: http://www.learningpython.com/2006/07/25/writing-a-custom-widget-using-pygtk/ http://pyjd.sourceforge.net/controls_tutorial.html * how easy is it, using the "new" or "custom" widget extension methodology of existing python GUI widget sets, to extend that widget set to "keep up" with modern GUI advancements and user expectations, as compared to enhancing web browser technology? actually, this is a deliberately misleading question, but it at least illustrates that it's damn hard for GUI widget set developers to "keep up". in fact, many GUI widget set developers are actually embedding web browser technology as a widget in order to avoid the problem! (pywebkitgtk, pyqtwebkit etc.) * better question: how much time and money by large corporations with their associated vested interests is being invested into python GUI widget sets, as compared to how much by those same corporations into the W3C DOM Standards process and the resultant improvements and advances in web browser technology? * final question: how easy is it to create python "wrappers" around DOM browser technology, thus leveraging and riding on the back of the _vast_ amounts of effort and money being poured into web browser technology? answer for MSHTML (aka Trident Layout Engine): using python-comtypes - 3 weeks. answer for WebKit: using glib/gobject and pygobject "codegen" to augment pywebkitgtk - 12 weeks answer for XulRunner: using python-hulahop and python-xpcom - 2 weeks. answer for Opera's engine: unknown, because the developer hasn't responded yet. (it's qt-based, so it would be estimated around 12 weeks, if they haven't already done the work). so can you see where this is at? and that's why pyjamas/pyjamas- desktop exists. a _completely_ non-corporate-funded, _tiny_ team is riding on the back of the vast amounts of money and resources available to google, apple, nokia, microsoft, mozilla foundation and so on, and we're sitting back and offering it as free software to people to create applications that are as powerful as the underlying web technology on which the pyjamas UI toolkit is based. and with the addition of WebGL (3D SVG) and HTML5 (Video etc.), web technology is becoming pretty powerful. so this is why it can be claimed that pyjamas competes with silverlight and with adobe AIR/Flash, and it's not to do with pyjamas "per se": pyjamas is just a "leveraging" technology to ge
pyjsglade: GTK-glade-like UI builder for pyjamas
https://sourceforge.net/projects/pyjsglade/ kees bos, the primary programmer who added all of the incredible python features to the pyjs compiler, such as support for yield, long data type and much more, has just started a project "pyjsglade". its purpose is the same as that of GTK glade: allow developers to build GUIs based on an XML file format. whilst he's pretty much literally only just begun the project, it's a) useable because he needs it to be, for a work-related project b) kees is such a ridiculously competent programmer that by the time you read this it'll likely be 50% functional :) anyway, i thought i'd just let people informally know. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: historic grail python browser "semi-recovered"
On Jun 10, 6:17 pm, MRAB wrote:
> lkcl wrote:
> > On Jun 9, 11:03 pm, rantingrick wrote:
> >> On Jun 9, 4:29 pm, lkcl wrote:
>
> >>> um, please don't ask me why but i foundgrail, the python-based web
> >>>browser, and have managed to hack it into submission sufficiently to
> >>> view e.g.http://www.google.co.uk. out of sheer apathy i happened to
> >>> have python2.4 still installed which was the only way i could get it
> >>> to run without having to rewrite regex expressions (which i don't
> >>> understand).
> >>> if anyone else would be interested in resurrecting this historic web
> >>>browser, just for fits and giggles, please let me know.
> >> Hi lkcl,
>
> >> My current conquest to bring a new (or fix the current GUI) in
> >> Python's stdlib is receiving much resistance. I many need a project to
> >> convince my opponents of my worth. Tell you what i do, send me a text
> >> file with a pathname and all the line numbers that have broken regexs
> >> using a common sep --space is fine for me-- and i'll fix them for you.
> >> Here is a sample...
>
> > ok i've committed a file REGEX.CONVERSIONS.REQUIRED into the git
> > repository,
> >http://github.com/lkcl/grailbrowser
> > git://github.com/lkcl/grailbrowser.git
>
> > i used "grep -n" so it's filename:lineno: {ignore the actual stuff}
>
> > unfortunately, SGMLLexer.py contains some _vast_ regexs spanning 5-6
> > lines, which means that a simple grep ain't gonna cut it. there's a
> > batch of regex's spanning from line 650 to line 699 and a few more
> > besides.
>
> > of course, it has to be borne in mind that this code was written for
> > python 1.5 initially, at a time when python xml/sax/dom/sgml code
> > probably didn't exist.
>
> > but leaving aside the fact that it all needs to be ripped up and
> > modernised i'm more concerned about getting these 35,000 lines of code
> > operational, doing as small transitions as possible.
>
> The regex module was called 'regex'.
yes. there's a python module in 2.4 called reconvert.py which can
"understand" and convert _most_ regex expressions to re.
> I see that the name 're' is used as
> a name in the code.
bizarre, isn't it?
--
http://mail.python.org/mailman/listinfo/python-list
Re: historic grail python browser "semi-recovered"
On Jun 9, 11:03 pm, rantingrick wrote:
> On Jun 9, 4:29 pm, lkcl wrote:
>
> > um, please don't ask me why but i foundgrail, the python-based web
> >browser, and have managed to hack it into submission sufficiently to
> > view e.g.http://www.google.co.uk. out of sheer apathy i happened to
> > have python2.4 still installed which was the only way i could get it
> > to run without having to rewrite regex expressions (which i don't
> > understand).
>
> > if anyone else would be interested in resurrecting this historic web
> >browser, just for fits and giggles, please let me know.
>
> Hi lkcl,
>
> My current conquest to bring a new (or fix the current GUI) in
> Python's stdlib is receiving much resistance. I many need a project to
> convince my opponents of my worth. Tell you what i do, send me a text
> file with a pathname and all the line numbers that have broken regexs
> using a common sep --space is fine for me-- and i'll fix them for you.
> Here is a sample...
ok i've committed a file REGEX.CONVERSIONS.REQUIRED into the git
repository,
http://github.com/lkcl/grailbrowser
git://github.com/lkcl/grailbrowser.git
i used "grep -n" so it's filename:lineno: {ignore the actual stuff}
unfortunately, SGMLLexer.py contains some _vast_ regexs spanning 5-6
lines, which means that a simple grep ain't gonna cut it. there's a
batch of regex's spanning from line 650 to line 699 and a few more
besides.
of course, it has to be borne in mind that this code was written for
python 1.5 initially, at a time when python xml/sax/dom/sgml code
probably didn't exist.
but leaving aside the fact that it all needs to be ripped up and
modernised i'm more concerned about getting these 35,000 lines of code
operational, doing as small transitions as possible.
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: historic grail python browser "semi-recovered"
On Jun 9, 10:58 pm, Thomas Jollans wrote: > give us a copy then, just for the laughs. ^^ Post it on bitbucket, > maybe? (or send me a copy and I'll do it) http://github.com/lkcl/grailbrowser remember it only works on python2.4 or less right now! -- http://mail.python.org/mailman/listinfo/python-list
Re: historic grail python browser "semi-recovered"
On Jun 9, 11:03 pm, rantingrick wrote: > On Jun 9, 4:29 pm, lkcl wrote: > > > um, please don't ask me why but i foundgrail, the python-based web > >browser, and have managed to hack it into submission sufficiently to > > view e.g.http://www.google.co.uk. out of sheer apathy i happened to > > have python2.4 still installed which was the only way i could get it > > to run without having to rewrite regex expressions (which i don't > > understand). > > > if anyone else would be interested in resurrecting this historic web > >browser, just for fits and giggles, please let me know. > > Hi lkcl, > > My current conquest to bring a new (or fix the current GUI) in > Python's stdlib is receiving much resistance. I many need a project to > convince my opponents of my worth. Tell you what i do, send me a text > file with a pathname and all the line numbers that have broken regexs > using a common sep --space is fine for me-- and i'll fix them for you. yegods - i'm going to have to create a python script to do that :) shouldn't take me 30 mins. i'll also upload the source of grail to github.com or summink, first. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: historic grail python browser "semi-recovered"
On Jun 9, 9:29 pm, lkcl wrote: > if anyone else would be interested in resurrecting this historic ... "historic, archaic, dinosaur-driven, vastly-overrated but one-of- a-kind and without precedent before or since" web browser... l. p.s. except for paul bonser's "pybrowser" which he's delayed working on, despite a heck of a lot of groundwork. -- http://mail.python.org/mailman/listinfo/python-list
historic grail python browser "semi-recovered"
um, please don't ask me why but i found grail, the python-based web browser, and have managed to hack it into submission sufficiently to view e.g. http://www.google.co.uk. out of sheer apathy i happened to have python2.4 still installed which was the only way i could get it to run without having to rewrite regex expressions (which i don't understand). if anyone else would be interested in resurrecting this historic web browser, just for fits and giggles, please let me know. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there a way to warn about missing modules *without* running python?
On Jun 5, 2:16 pm, Steven D'Aprano wrote: > Neither Python, nor Javascript (as far as I know -- I welcome > corrections) do static linking. for the command-line versions of javascript such as spidermonkey, i believe that a keyword/function is dropped into the global namespace - "load", which take one argument (a filename). in browsers, it's much more waffly: anything that is tagged as "script language='javascript'" gets executed in a global namespace (into which two strategically critical global variables have been dropped: "window" and "document", which is really the only "real" clue that you have that this is javascript in a web browser engine, not javascript at a command-line). so, if the DOM happens to ever get modified (typically using AJAX), such that an additional node with a tag of "script" and an attribute "language='javascript'" happens to get added, the browser engine _happens_ to notice and _happens_ to execute the resultant newly-added javascript. this well-known but horribly archaic technique is about as close to dynamic module loading that you're ever likely to get in web browsers. everything else is "static", so to speak, and _everything_ operates in one monster global namespace (on a per-page basis). ... but i digress :) > Python modules are, conceptually speaking, like DLLs. They are loaded at > runtime, not at compile time. This has many advantages over static > linking, but some disadvantages as well. thank you, steve - i believe this is the crux of the matter (which terry's analogy expanded on). much appreciated the replies. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there a way to warn about missing modules *without* running python?
On Jun 5, 7:24 pm, Terry Reedy wrote: > On 6/5/2010 9:42 AM, lkcl wrote: > > > if someone could perhaps explain this (in a different way from me), in > > the context of "python the programming language" and "python the > >http://python.orginterpreter";, i.e. having absolutely nothing to do > > withpyjamas, i would be most grateful, and it would benefit that > > user's understanding of python. > > I do not know the background of your user, but here is my try: > Loading a Python module at runtime is like loading a song, picture, or > web page. An import statement is like a web page link. thank you, terry - that's a good analogy. l. -- http://mail.python.org/mailman/listinfo/python-list
is there a way to warn about missing modules *without* running python?
folks, hi, although i know the answer to this question, i'm having difficulty explaining it, to a user on the pyjamas list. i was therefore wondering if somebody could also provide an answer, on this list, to which i can refer the user. to make it clear: the user is confused as to why the pyjamas compiler (which strictly speaking isn't actually a compiler it's a "language translator", translating from one dynamic language into another dynamic language, feature-for-feature, concept-for-concept) is _not_ making any effort to help or advise the user at *COMPILE TIME* when they make the mistake of trying to import a module that does not exist. they are confused as to why they have to go to all the trouble of executing the [translated] javascript code in a web browser engine, where web browser engines are known to be a complete pain as far as debugging is concerned, just to find out that they made a mistake in mis-naming an import module. in other words, they are confusing the concept of "python as a dynamic language" with the concept of "compiler in the traditional static- language-such-as-c-or-c++ sense". i've tried explaining that the answer is because this has absolutely -all to do with pyjamas, and has everything to do with the http://python.org programming language, but i'm not getting through to them. if someone could perhaps explain this (in a different way from me), in the context of "python the programming language" and "python the http://python.org interpreter", i.e. having absolutely nothing to do with pyjamas, i would be most grateful, and it would benefit that user's understanding of python. many thanks, l. ref: http://groups.google.com/group/pyjamas-dev/browse_thread/thread/64cf948082bfec52?hl=en_US -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is cool!!
On Mar 23, 4:55 pm, Jose Manuel wrote: > I have been learning Python, and it is amazing I am using the > tutorial that comes with the official distribution. > > At the end my goal is to develop applied mathematic in engineering > applications to be published on the Web, specially on app. oriented to > simulations and control systems, I was about to start learning Java > but I found Python which seems easier to learn that Java. > > Would it be easy to integrate Python in Web pages with HTML? I have > read many info on Internet saying it is, and I hope so jose, hi, perhaps it should be pointed out that there are four completely different types of answers, as outlined here: http://www.advogato.org/article/993.html python can be involved in absolutely every single one of those four separate types of answers. you should ideally read that article to determine which of the four approaches is most appropriate for you, and let people here know; and then people here will be able to respond accordingly and advise you accurately and with less time spent on their part, in guessing what it is that you want to do. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is cool!!
On Mar 25, 3:01 pm, Bruno Desthuilliers wrote: > Jose Manuel a écrit : > > > I have been learning Python, and it is amazing I am using the > > tutorial that comes with the official distribution. > > > At the end my goal is to develop applied mathematic in engineering > > applications to be published on the Web, specially on app. oriented to > > simulations and control systems, I was about to start learning Java > > but I found Python which seems easier to learn that Java. > > Python is indeed quite lightweight when compared to Java. But it has > it's share of non-obvious features, dark corners, gotchas, and plain > warts too. good god. it does?? :) that's news to me, bruno! where? i haven't found _any_ of those things - it's aaalll been blindingly obvious and... ok maybe not metaclasses i alllmost grok those :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On May 2, 7:16 am, Wolfgang Strobl wrote: > lkcl : > > > at least _some_ input would be good! the knowledge doesn't have to > >be there: just the bugreports saying "there's a problem and here's > >exactly how you reproduce it" would be a start! > >> So please make it simpler for more people to help. > > ... how?? there's a bugtracker, wiki, svn repository, over 30 > >examples and a developer list. the code really _is_ very very small > >(the UI widget set, with around 75 widgets, minus the license header > >text is only around 4,000 lines _total_, making it very very simple > >and very very easy for people to get used to). suggestions welcome! > > Well, the bunch of programming languages and APIs I collected over the > years is large enough already. These days I prefer to stay with python > and c, spiced with an occasional domain specific language. That's why I > was attracted bypyjamas, to begin with!. If I'd like to program using > Eclipse and Java or fool around with JavaScript, I'd do just that. But I > don't. IMHO, that ist a general problem of translation tools - they > attract the wrong people, from the point of view a developer who looks > for people sharing some of the workload. :-) > > So, Luke, I can only answer your question from the point of view of > somebody who is mostly a potentional consumer of your work, and most > problably not another developer. If you want to delegate some work you'd > like not to do yourself (for example because you prefer designing and > coding to testing and reorganizing and polishing the docs), than you > have at least to _define_ those pieces and to monitor progress. the project's run on a much much simpler basis than that: anyone who wants to contribute absolutely anything, ask, and you get svn access - simple as that. you get told what the rules are (code that's committed to trunk must work, must have a commit message, must be "single-purpose", must follow PEP8 mostly and so on - the usual obvious stuff). that's pretty much it. the project really _is_ run on the basis of it being "a useful tool for the developers, and if other people benefit from it that's great". kees wanted a better interpreter, i granted him svn rights, and in about four to five months he absolutely smacked the compiler into incredible and amazing shape, including implementing "yield" - fully and properly across _all_ browsers so that it passes even the python regression tests. me, personally, i would be happy with the state the compiler was in, back in 0.5, because that limited functionality served _my_ purposes. but, for kees, it definitely didn't: he wanted to be able to compile http://puremvc.org python code "as-is" and that meant that the compiler _had_ to be improved. so it's much _much_ simpler than "delegation of tasks". someone wants to do something? _great_ - knock yourself out. that having been said: we do have a TODO list. unsurprisingly, it's in the top level directory, called "TODO" :) > >> > then please issue bugreports for as many as you feel comfortable > >> >with / have time for. > > Well, ok. I put my notes in a Google chart, see > http://spreadsheets.google.com/pub?key=0Au5LhqNQyrfCdGpDbTVjZFJwSERzV... ouh, absolutely absolutely fantastic, thank you. ok. yep. the Controls one, someone provided a patch contributing the 2-axis slider and base class, but it was a bit of a mess, and i belieeve it only compile(s/d) with --strict. i've made some changes, _thank_ you for pointing these errors out, i've recorded them in issues. > I had to write a short patch against compile.py (see issue 397) in order > to make it compile the showcase examples on Windows. okaay, good stuff. > In addition, I've tried to create Selenium tests for automating the time > consuming job of checking all those examples, using Selenium IDE in > Firefox. I was my first experience using this against Ajax apps. The > results are somewhat mixed. Playing a round of "lightout" was a breeze, > but so far I hadn't much luck in driving the showcase example(s). I > didn't try very hard, though, because I ran out of time, as I do now. hell, your input has been incredibly valuable, i'm very grateful for the time you've put in. btw yes i started doing a UITest because yes, it's silly to have to do so much manual work. by writing a UITest app the goal is to be able to run the tests automated even across pyjd platforms. it'd be possible but raather tricky to run selenium under xulrunner/pyjd. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On Apr 29, 6:37 am, Wolfgang Strobl wrote:
> Look at it from the point of view of people walking by, trying to decide
> whether they should invest some of their time into digging into yet
> another framework and library.
yes. _their_ time - not mine. the pyjamas project has always been
done on the basis that skilled software developers such as myself and
others ... how-to-say... "invite" other people to benefit from the
fact that they want to have tools which make _their_ lives easier.
as we receive absolutely no money of any kind from any sponsor or
other free software organisation nor from any corporation, there _is_
no money to spend on doing the "usual" kind of free software project,
where the developers are paid / funded to deal with issues effectively
"for free".
so instead i encourage and invite people to contribute, and some do,
and some don't: the end-result is the product of everyone's collective
input.
>
>
> >> and that there is no way of
> >> telling, other than by trying each one out in turn?
>
> > yepp that's correct. across multiple browsers and across multiple
> >desktop platforms. nine in total. which is why i asked for community
> >input this time.
>
> It's hard to come by with valuable input when the baseline - what is
> expected to work under which circumstances is unknown. Don't expect the
> community having as much knowledge about all the relevant topics as you
> have.
at least _some_ input would be good! the knowledge doesn't have to
be there: just the bugreports saying "there's a problem and here's
exactly how you reproduce it" would be a start!
> So please make it simpler for more people to help.
... how?? there's a bugtracker, wiki, svn repository, over 30
examples and a developer list. the code really _is_ very very small
(the UI widget set, with around 75 widgets, minus the license header
text is only around 4,000 lines _total_, making it very very simple
and very very easy for people to get used to). suggestions welcome!
> Other people have
> other projects, where they invest some of their own time and money in.
yes. been there. didn't receive any return on investment. did some
projects. received about 25% of required money to pay bills. need
£15k pa; receiving approximately £7-8k.
> >> I didn't look at
> >> every example again, but AFAIK, this didn't change with 0.7. (Tried with
> >> Python 2.6.4/5 on WinXP/7 with Firefox and Chrome, if that matters).
>
> > then please issue bugreports for as many as you feel comfortable
> >with / have time for.
>
> Ok, will do.
thanks. i fixed the lightout one, don't worry about that.
> > no, because they're all intended to work. ohh... wait... are you
> >referring to some of the django-based ones?
>
> No. Having written a few small django apps myself, I'm certainly aware
> about such dependencies. But are you aware that's there is no simple way
> to tell whether certain apps have environment dependencies like this?
> Avoiding examples depending on django is obvious. What about the
> infohierarchy sample, for example?
that's reading text files using HTTPRequest (just like the Bookreader
and Slideshow examples), so there's no dependency like that.
each of the examples, if it has dependencies such as django, it's
assumed that you know how to install and configure django, and there's
instructions in the README to set things up.
> I'm talking about messages like
> lightout TypeError: lightout.RootPanel().,get is no function
> and such.
hooray! thank you! a bugreport! ok, that was a one line fix:
@@ -85,6 +85,6 @@ class Game(SimplePanel):
if __name__ == '__main__':
pyjd.setup("public/lightout.html")
game = Game(3)
-RootPanel().get('game').add(game)
+RootPanel('game').add(game)
so, don't worry about that one, it's done. small change to the API
(to support something that someone else needed) had knock-on effects.
> I'll make a list over the weekend.
thank you. greatly appreciated.
> >> Given my original motivation for looking into it - may I ask whether
> >> there is a working example for a dnd operation, somewhere?
> > the person who started the port of gwt-dnd requested that they be
> >"left alone" to complete it, but then didn't. the use of java2py.py
> >and manual conversion i can do about 1000 lines per day, and people
> >i've guided before usually take about 3x longer than me. i don't have
> >money to work on even 1 line let alone 1000, so if you'd like to go
> >through the code, converting it and the examples, i'm happy to advise
> >(on thepyjamas-dev list so that other people can contribute as well
> >if they choose).
>
> Hey, I'm just asking, after looking around for a while and finding none,
> I'm not demanding anything.
no problem, i understood that you weren't - i was just making it
clear that i know what's involved.
> Thanks for the detailed explaination of how to do a conversion, which
> I've deleted here for brevity. I'll give it a try, but it will requir
Re: pyjamas 0.7 released
On Apr 28, 7:00 am, Wolfgang Strobl wrote: > lkcl : > > > > > > >On Apr 25, 9:37 pm, Wolfgang Strobl wrote: > >> Daniel Fetchinson : > > >> >> for fits and giggles, to show what's possible in only 400 > >> >> lines of python, here is a game of asteroids, written by joe rumsey. > >> >> yes, it runs underpyjamas-desktop too. > > >> >> http://pyjs.org/examples/asteroids/public/Space.html > > >> >This URL returns a blank page for me on firefox 3.3.5 (linux) with and > >> >without adblock plus. > > >>http://pyjs.org/examples/asteroids/output/Space.htmlworks. (Firefox > >> 3.6.3 with ABP, Chrome 4.1) > > > yep. apologies. didn't want to play asteroids, wanted to do a > >release. > > Sure. :-) But you made a very prominent reference to it. Btw., > bothhttp://pyjs.org/andhttp://code.google.com/p/pyjamas/still name 0.6 as > the current version. Shouldn't that be changed to 0.7? yes. haven't got round to it yet. > Two weeks ago, I played around with the trunk version, looking for an > working drag&drop example. I didn't find anything, but noticed some > unfinished code in a dnd subdirectory. Are you aware of the fact that > many of the examples just don't work no - because i specifically asked people, in the 0.7 pre-releases, to report any bugs found on http://code.google.com/p/pyjamas/issues and i said that once a certain amount of time had elapsed without receiving significant bugreports, i would do a release. > and that there is no way of > telling, other than by trying each one out in turn? yepp that's correct. across multiple browsers and across multiple desktop platforms. nine in total. which is why i asked for community input this time. for the 0.6 release i spent about a month of my own time and money doing the necessary verification, and i decided i wasn't going to place the entire burden of testing onto my own shoulders, this time, because pyjamas is a _community_ project and is _not_ funded by google, PSF, or any other organisation, foundation or company. > I didn't look at > every example again, but AFAIK, this didn't change with 0.7. (Tried with > Python 2.6.4/5 on WinXP/7 with Firefox and Chrome, if that matters). then please issue bugreports for as many as you feel comfortable with / have time for. i _did_ tell people this time that i was relying on community input more than for 0.6. thus, the "quality" of the release depends on collective input. > There are quite some impressive working examples, but the user > experience is somewhat lacking and hampered by stumbling over faulting > examples, IMHO. May I suggest to restrinct some overview page to the > working examples, only? no, because they're all intended to work. ohh... wait... are you referring to some of the django-based ones? no, you can't be, because the http://pyjs.org/examples page won't refer you to them. > Given my original motivation for looking into it - may I ask whether > there is a working example for a dnd operation, somewhere? the person who started the port of gwt-dnd requested that they be "left alone" to complete it, but then didn't. the use of java2py.py and manual conversion i can do about 1000 lines per day, and people i've guided before usually take about 3x longer than me. i don't have money to work on even 1 line let alone 1000, so if you'd like to go through the code, converting it and the examples, i'm happy to advise (on the pyjamas-dev list so that other people can contribute as well if they choose). it's quite straightforward, and somewhat mind-numbing and detail- orientated: the absolute most important thing is _not_ to "get creative", but just "trust" the original gwt-dnd code and simply do "rote" conversion. java2py.py does 95% of the work: it's interfaces, sub-classes and function/operator overloading where things get a little hairy. oh, and references to "self", a concept which doesn't exist in java (and java2py.py can't help with except in one special and obvious case). other than that: there _is_ sufficient in there to simply "roll your own" drag-and-drop. you have access to mouse events; you can create state... it's not hard. but, if you're counting on a _lot_ of dnd work, doing the semi-automated conversion of gwt-dnd would be a goood idea. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On Apr 26, 11:25 pm, Patrick Maupin wrote: > On Apr 26, 4:12 pm, lkcl wrote: > > > and, given that you can use AJAX (e.g. JSONRPC) to communicate with a > > server-side component, installed on 127.0.0.1 and effectively do the > > exact same thing, nobody bothers. > > I suppose, but again, that pushes off the security thing. There are a > lot of obvious ways to make unintended security holes in a 127.0.0.1 > application, not to an experienced web developer. by starting the browser at a URL which can only used once, you can effectively do the same trick that X-Server X-Auth "magic cookies" does. > so I'm sure there are also a lot of ways that would be > unobvious to this security non-expert. And, of course, the real > dealbreaker is, it still requires a separate install. not necessarily. luis pamirez created pygtkweb (a reimplementation of gtk widgets, to be compiled to javascript, to run in a web browser) and he created it as a stand-alone app that 1) fired off a web browser 2) ran a small cgi-bin-esque web service 3) served static (pre- compiled) pages 4) served AJAX to the compiled app. with pyjd, that "step 1" can be bypassed or more specifically step 1 and 2 can be combined into the _one_ python app (two threads / processes); you effectively combine the "start the window with the browser engine in it" step with the "start a mini web server" step. so it can be done: it's just not "immediately obvious". l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On Apr 26, 6:52 pm, Patrick Maupin wrote:
> On Apr 26, 8:44 am, lkcl wrote:
>
> > the purpose of browsers is to isolate the application, restrict its
> > access to the rest of the desktop and OS, so that random applications
> > cannot go digging around on your private data.
>
> Well, I would agree that a "requirement" for the browser is to help
> insure the user's safety, but would argue that the *purpose* is
> somewhat more functional than that :-)
we know :)
> > many browsers _used_ to allow access to local files etc. but ...
> > yeah.
>
> I know. But, with most browsers, you can say "yes, I know I'm
> downloading this Java program.
... which requires a java plugin
> I know it can have its way with my hard
> drive. Trust me; I know what I'm doing here." Same thing with Adobe
> or Microsoft stuff: silverlight,
plugin
> AIR,
aka webkit (modified) plus plugins
> flash,
plugin
> PDFs.
often done as a plugin (e.g. mozplugger for firefox)
> Basically, the
> browser delegates ALL security control at that point. I just think it
> would be nice if the browser could delegate a _little_ security
> control to the user ("allow this JavaScript program to read/write
> arbitrary files in this directory"; possibly with a total file size
> limitation) for programs that can run inside the browser.
on IE, this is already possible - without needing plugins. "active
scripting". however, it requires security settings that people simply
aren't equipped to correctly modify.
> > so i think you will be able to do what you describe _if_ you provide
> > a browser plugin which adds the required functionality.
>
> Agreed. Alternatively, of course, you could have code to let the user
> "download" to a local file from the application's local storage area
> for backup purposes, but that seems suboptimal.
>
> > google gears would be a good place to start (i've part-ported GWT
> > Gears topyjamas- the SQL storage modules - to demonstrate what's
> > needed).
>
> I think even gears assumes a database under the browser's control; not
> an arbitrary node in the filesystem. Also, I think gears is no longer
> being developed. Of course, gears could be OK as a starting point,
> but really what you are saying is that everybody wanting to use this
> new file local storage feature would need an add-on. I agree that's
> probable, but in that case it's only really worth doing if a lot of
> projects would use it.
preeeciselyyy. which is why nobody does it.
and, given that you can use AJAX (e.g. JSONRPC) to communicate with a
server-side component, installed on 127.0.0.1 and effectively do the
exact same thing, nobody bothers.
the JSONRPC stuff is pretty trivial (if annoying by the fact that
it's asynchronous function calls, client-side) - and there are half a
dozen server-side implementations. the ones we recommend people use
with pyjamas are actually damn good: decorators turn an "ordinary"
function into a JSONRPC service with a single import and a single line
of code (decorator) per function. that's _it_. the actual
implementation, aside from "apt-get install simplejson" is about
_thirty_ lines of code (incredibly) for joining up JSONRPC to django
or web2py etc. etc.
it's so small an amount of code that the django developers are
refusing to include it in the standard distribution, because it
doesn't look scarily complicated enough, doesn't make programming with
JSONRPC difficult enough for them, and generally makes life "too
easy". i love it when programmers get scared by code that appears to
be "too easy" and "not stressful enough to be acceptable", because
then they stay away from me, thank goodness.
but - yeah: JSONRPC's definitely your most sensible pragmatic
option. server-side you can then do absolutely anything. if you use
pyjs, you then have the advantage that the application will still work
as pure python under pyjd _even_ though it uses HTTPRequest, because i
made damn sure that the XmlHTTPRequest objects which you _expect_ to
use "javascript-only" _still_ work even under the three ports
(pywebkitgtk, xulrunner and MSHTML). (that was fun-and-games and
there's still massive repercussions with the fucking crack-heads from
the webkit team over the access to XmlHTTPRequest from glib/gobject...
just don't ask for details... )
> > if however you completely ignore browsers from the equation, by
> > virtue of having to piss about writing c code, then yes, you can use
> >pyjamas-desktop. at that point, you have _full_ access to the entire
> > OS and system, because you're firing up the web browser
Re: pyjamas 0.7 released
On Apr 25, 9:37 pm, Wolfgang Strobl wrote: > Daniel Fetchinson : > > >> for fits and giggles, to show what's possible in only 400 > >> lines of python, here is a game of asteroids, written by joe rumsey. > >> yes, it runs underpyjamas-desktop too. > > >> http://pyjs.org/examples/asteroids/public/Space.html > > >This URL returns a blank page for me on firefox 3.3.5 (linux) with and > >without adblock plus. > > http://pyjs.org/examples/asteroids/output/Space.html works. (Firefox > 3.6.3 with ABP, Chrome 4.1) yep. apologies. didn't want to play asteroids, wanted to do a release. joe has done an updated version (that only works with pyjs not pyjd) which has sound. it uses a hidden iframe containing an adobe swf plugin, and javascript to communicate with the hidden iframe, sending it "commands" to play certain sounds at certain volumes. once i work out how to do the same trick in pyjd, it'll get added. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On Apr 25, 8:38 pm, Patrick Maupin wrote: > On Apr 25, 8:49 am, Luke Kenneth Casson Leighton > wrote: > > >pyjamas- the stand-alone python-to-javascript compiler, and separate > > GUI Widget Toolkit, has its 0.7 release, today. this has been much > > delayed, in order to allow the community plenty of time between the > > 0.7pre2 release and the final release, to review and test all the > > examples. > > I know I'm a Luddite, but what I'd really love to see to go with this > is an easy way for the application, the browser, and the user to all > agree that this particular application can read and write arbitrary > files in a particular local directory. you'll have to be a bit clearer about what you mean, because it's probably perfectly possible with one of the pyjamas-desktop ports, but that would leave the browsers "out in the cold", thus defeating the purpose of pyjamas being cross-platform, cross-browser, cross-desktop and cross-widget-set. > A Python program you don't have to install, that executes really fast > on one of the newer JavaScript JIT engines, with its own purely local > data in files in a simple text format in a directory specified by the > user, the purpose of browsers is to isolate the application, restrict its access to the rest of the desktop and OS, so that random applications cannot go digging around on your private data. many browsers _used_ to allow access to local files etc. but ... yeah. so i think you will be able to do what you describe _if_ you provide a browser plugin which adds the required functionality. google gears would be a good place to start (i've part-ported GWT Gears to pyjamas - the SQL storage modules - to demonstrate what's needed). if however you completely ignore browsers from the equation, by virtue of having to piss about writing c code, then yes, you can use pyjamas-desktop. at that point, you have _full_ access to the entire OS and system, because you're firing up the web browser engine as a python application. i've done something like this with pyjdwm - http://sf.net/projects/pyjdwm l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas 0.7 released
On Apr 26, 12:45 pm, Jean-Michel Pichavant wrote: > Luke Kenneth Casson Leighton wrote: > > > [snip] > > Am I the only one getting this error ? yes, because you're the only one using easy_install. you'll need to read and follow the instructions in README and INSTALL.txt the installation procedure requires, without fail, that you run "python bootstrap.py" which can NOT be added to a standard "setup.py" script without causing massive problems. it is imperative that the python source which is part of the pyjamas core libraries be kept ABSOLUTELY separate from standard http://python.org core libraries. implementations of os.py, sys.py, md5.py and many more CANNOT be allowed to be part of the "standard" http://python.org paths. these libraries cannot be treated as "code" these libraries cannot be treated as "data". the dumb-system called "easy_install" cannot cope with the necessary distinction; it does not _have_ a means to treat libraries as "critical" but neither "code which gets installed in the standard place in the standard way" nor "data". thus we cannot use it. thus, you need to read the instructions, and follow them. l. > easy_install --prefix /home/jeanmichel -mpyjamas > Searching forpyjamas > Readinghttp://pypi.python.org/simple/pyjamas/ > Readinghttp://pyjs.org > Best match:pyjamas0.7 > Downloadinghttp://pypi.python.org/packages/source/P/Pyjamas/pyjamas-0.7.tgz#md5=... > Processingpyjamas-0.7.tgz > error: Couldn't find a setup script in > /tmp/easy_install-y3peDk/pyjamas-0.7.tgz > [1] 12487 exit 1 easy_install --prefix /home/jeanmichel -mpyjamas -- http://mail.python.org/mailman/listinfo/python-list
Re: Interacting With Another Script
On Mar 11, 2:16 am, alex23 wrote:
> Victor Subervi wrote:
> > > There's a program (vpopmail) that has commands which, when called, request
> > > input ("email address", "password", etc.) from the command line. I would
> > > like to build a TTW interface for my clients to use that interacts with
> > > these commands.
>
> The Pexpect[1] module is pretty much aimed at doing exactly this.
>
> 1:http://www.noah.org/wiki/Pexpect
i also made some patches to telnetlib.py back in 2000, creating an
expectlib.py and then using that in telnetlib.py. the code is still
in python's bug tracker, and no fucker has integrated it, despite it
still being valid, relevant and useful, in ten years since.
the code basically creates a base class from which the "old"
telnetlib derives, but it also provides an additional class
TelnetPopen which, as you might expect, can be used to run python
popen and then use _all_ of the functions in telnetlib which should
never have been hard-coded as specifically being associated with the
Telnet class (hence why i moved them to expectlib.py).
it's therefore possible to use it to do ssh "as if" it was telnet
(remember to use the -t option to stop terminal translation, and
remember to use TelnetPopen because otherwise you have to patch ssh to
accept passwords on the command-line!)
in order to avoid clashes with telnetlib.py, i often rename it to
telnetlib2.py and i believe i've regularly published them in other
free software projects, so you should find it with a search for
"telnetlib2.py". if you can't specifically find the two modules, let
me know, and i'll make them available somewhere.
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: (snmp code) perl to python
On Apr 25, 9:41 am, Shabbir Ahmed wrote: > hi hope all are doing good, i have code written in perl which quries > too many devices and then stores the result in mysqldb, whiel shifting > to python and googling i heared of and studied google asynch python > code, now i wanted to use it n convert my perl code to it but i have > some problem. > > 1. this class creates forks every snmp query and returns un ordered > result without any information that which oid returned which result, > where as in my code i query all only if a parent oid returns true, now > i dont know how to read specific oid. > > algo of perl code, > > read all the ips and communities from mysql then fork function for > every router so that all the equipment are queried at once, it creates > that much saperate process of equipment ips, > > function that is forked: > loop for all the interfaces: check if the inteface is up > -> if so read the interface ips. > -> save result in mysql tables. > > kindly help me convert this code to python or make this logic in > python. if the code is particularly long (greater than 2,000 lines) then you might wish to look at java2py.py and use it as the basis to write a "dumb" assistant in doing much of the code-conversion: http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/contrib/java2py.py?revision=1572&content-type=text%2Fplain this program is _not_ parser-based (yacc, ply, oMeta2) it is line- based and state-based. specific assumptions are made about the code layout (braces in K&R formatting style for example) and, thanks to the high code-quality of the code it was used to translate (GWT) this was not in the slightest bit a problem. so, _in combination with a code-cleaner_ such as "indent", which regularises the formatting of whatever god-awful-looking perl you want to translate, the approach indicated by java2py.py will save you a lot of time and mistakes. think about it, even if the code you want to translate is 500 lines. that's 500+ lines you need to rewrite, whereas something as simple as 267 lines of python could help automate that process of conversion. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: look at the google code
On Feb 19, 10:41 am, Allison Vollmann wrote: > http://code.google.com/p/pyjamas/ > > Last update from yesterday, is the same project? only the tarballs are maintained on there, and the wiki and the issue tracker. we couldn't get control of that site for quite some time so started using sourceforget for svn, but the issue tracker on sourceforget is truly dreadful. basically there's bits of pyjamas splattered all over the place in a pick-n-mix setup :) mostly this is for the convenience of the key developers - welcome to free software, where the developers do what they like because it makes _their_ lives easier... l. -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to pyjamas?
On Feb 19, 2:43 pm, John Pinner wrote: > It appears that, in trying to cut down spm, somone chahnged a DNS > entry and screwed it up : it shouldbe back before long. yep. i've now got access to the web interface for the dns whois records. they got poo'd up (only one entry) and then the person who made the changes was ill for a couple of days. i needed to change the DNS server to one that i control (rather than a "dumb" get-free-hosting-for-£1.99-a-month provider so that i could add http://wiki.pyjs.org (using a pyjamas-based wiki of course), move away from sourceforge VHOSTS, and generally set things up a little bit better. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie advice
On Oct 29, 7:00 am, alex23 wrote: > However, if you're already comfortable with HTML/CSS, I'd recommend > taking a look atPyjamas, which started as a port of the Google Web > Toolkit, taking Python code and compiling it into javascript. The > associated project,Pyjamas-Desktop, is a webkit-based desktop client/ > widget set; so ideally you only have to write one UI and it'll run > both on the web & the desktop. > > Pyjamas:http://pyjs.org/ > Pyjamas-Desktop:http://pyjd.sourceforge.net/ thank you for mentioning these, chris. the information on pyjd is slightly out-of-date. * pyjamas-desktop was merged into pyjamas as of the 0.6 release. * there are now three alternative back-ends for pyjamas-desktop, (just as there are three major web browser engines). MSHTML, xulrunner and webkit. Opera's engine cannot be included because Opera's developers have not responded to invitations to provide an engine / library to which python bindings can be added. when they have provided python bindings, a port of pyjd to use them can be done in approximately two weeks. * the webkit-based back-end is the least-recommended, due to intransigence of the webkit developer, mark rowe. mark rowe has shown consistent disrespect for free software contributions to make webkit with glib/ gobject bindings actually useful and useable, and has ensured that anyone who wishes to proceed with getting webkit its glib/gobject bindings will have an unacceptably hard time. efforts to work with the other webkit developers, which were proving successful, were deliberately destroyed by, and terminated by, mark rowe. * the MSHTML-based back-end is surprisingly the most successful of the three pyjd ports. it requires _very_ little in the way of libraries to be installed: only python-comtypes (at 250k) which is in complete contrast to the other ports, which require whopping 30mbyte installs of libraries and dependencies. * the xulrunner-based back-end is the best option for unix-based systems. the design of xulrunner's core infrastructure, XPCOM, however, is slightly ... "incomplete". it is based on DCOM, but does not provide the exact same capabilities as DCOM (no coclasses). the upshot is that current releases of xulrunner work perfectly well for _everything_ but 2D SVG Canvas "Image" loading. (i have a patch for xulrunner which fixes this one single error) so - it's a mixed and interesting bag of tricks. full and comprehensive non-javascript bindings to web technology seems to be a thoroughly misunderstood and underexploited area, with several variations on the same theme being available from several competitive sources. the nice thing about pyjamas is that just as pyjs makes all the differences "go away" when pyjamas apps are compiled to run in web browsers, pyjamas-desktop makes those differences "go away" when pyjamas apps are run as pure python on the desktop. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: imputil.py, is this a bug ?
On Nov 7, 2:20 am, "Gabriel Genellina" wrote:
> Yes, seems to be a bug. But given the current status of imputil, it's not
> likely to be fixed; certainly not in 2.5 which only gets security fixes
> now.
well, that bug's not the only one. the other one that i found, which
i have been specifically ordered not to report (that or _any_ python
bugs, of which there have been several discovered in the past eight
months), will have to wait until the python developers rescind that
order.
if the python community is lucky, by the time that decision is made, i
will not have forgotten what those bugs are.
> (that is, self.fs_imp.import_from_dir(item, name)). Or perhaps
> item.encode(sys.getdefaultfilesystemencoding()). str(item) definitively
> won't work with directory names containing non-ascii characters.
>
> Why are you using imputil in the first place?
it's an absolutely necessary and integral part of pyjamas-desktop
"platform overrides".
it's absolutely essential to track, in exactly the same manner in
which python "normally" performs importing, and to give the platform-
specific "overrides" a chance to get in there, first.
so, it is absolutely essential to have a correct working version of
imputil.py - and due to the bugs present, and the unwillingness of the
python team to fix those bugs, pyjamas-desktop is forced to maintain a
copy of imputil.py
the "platform" is set to e.g. hulahop, pywebkitgtk or mshtml,
depending on the decision made by the user or the developer to use a
particular browser engine. the platform name is stored in
pyjd.platform in exactly the same way that the system name is stored
in sys.platform.
the way that the platform-specific overrides works is to perform AST
translation of the module, and then to look for the exact same module
but in platform/{modulename}{platformname}.py and perform AST
translation of _that_ module as well.
then, at the top level, any global functions in the platform-specific
AST tree *replace* those in the "main" AST. likewise, a node-walk
along all methods in all classes of the platform-specific AST tree.
in this way, god-awful messy code like this:
Widget.py
class Widget:
def do_something(self):
if platform == 'mshtml':
# do something terrible and ugly
elif platform == 'pywebkitgtk':
# do something only marginally better
else:
# do the default W3C standards-compliant thing
def a_standard_function(self):
# do something normal that all the browser engines get right
can be replaced by three files, each of which encodes *only* the
logic associated with the god-awful ugliness of each browser:
Widget.py
class Widget:
def do_something(self):
# do the default W3C standards-compliant thing
def a_standard_function(self):
# do something normal that all the browser engines get right
platform/Widgetpywebkitgtk.py
class Widget:
def do_something(self):
# do something only marginally better
platform/Widgetmshtml.py
class Widget:
def do_something(self):
# do something terrible and ugly
a similar trick could in fact be deployed to drastically simplify the
layout of e.g. distutils, _espeeecially_ the compiler and linker
modules, by using sys.platform as the "override", or, given that
that's not entirely the whole decision-making process, as i noted when
doing the mingw32 port of python, it would be better to set something
like distutils.platform and to use that.
however, although the technique could be used in the distutils/
ccompiler.py case, the level of complexity of the code (the size of
each "override"), and the small number of actual modules, means that
there isn't actually that much benefit in deploying this AST-
overriding technique.
in the pyjamas API, however, with over 75 user-interface modules, and
over 1200 functions, any one of which could be over-ridden by _eight_
separate platforms, each with their own quirks that can usually be
handled with one or two lines of code, the AST-merging idea that james
tauber came up with is an absolute god-send.
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: some site login problem help plz..
On Oct 5, 8:26 am, "Diez B. Roggisch" wrote:
> james27 wrote:
>
> > hello..
> > im new to python.
> > i have some problem with mechanize.
> > before i was used mechanize with no problem.
> > but i couldn't success login with some site.
> > for several days i was looked for solution but failed.
> > my problem is , login is no probelm but can't retrieve html source code
> > from opened site.
> > actually only can read some small html code, such like below.
>
> >
> >
> > location.replace("http://www.naver.com";);
> >
> >
>
> > i want to retrive full html source code..but i can't . i was try with
> > twill and mechanize and urllib and so on.
> > i have no idea.. anyone can help me?
>
> Your problem is that the site usesJavaScriptto replace itself. Mechanize
> can't do anything about that. You might have more luck with scripting a
> browser. No idea if there are any special packages available for that
> though.
yes, there are. i've mentioned this a few times, on
comp.lang.python,
(so you can search for them) and have the instances documented here:
http://wiki.python.org/moin/WebBrowserProgramming
basically, you're not going to like this, but you actually need
a _full_ web browser engine, and to _execute_ the javascript.
then, after a suitable period of time (or after the engine's
"stopped executing" callback has been called, if it has one)
you can then node-walk the DOM of the engine, grab the engine's
document.body.innerHTML property, or use the engine's built-in
XPath support (if it has it) to find specific parts of the DOM
faster than if you extracted the text (into lxml etc).
you should not be shocked by this - by the fact that it takes
a whopping 10 or 20mb library, including a graphical display
mechanism, to execute a few bits of javascript.
also, if you ask him nicely, flier liu is currently working on
http://code.google.com/p/pyv8 and on implementing the W3C DOM
standard as a "daemon" service (i.e. with no GUI component) and
he might be able to help you out. the pyv8 project comes with
an example w3c.py file which implements DOM partially, but i
know he's done a lot more.
so - it's all doable, but for a given value of "do" :)
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: AJAX Widget Framework
On Oct 1, 6:01 pm, Laszlo Nagy wrote: > I'm looking for an open source, AJAX based widget/windowing framework. > Here is what I need: > > - end user opens up a browser, points it to a URL, logs in > - on the server site, sits my application, creating a new session for > each user that is logged in > - on the server site, I create windows(frames), put widgets on them, > write event handlers etc. Just like with wx or pygtk. > - However, windows are created in the user's browser, and events are > triggered by Javascript, and sent back to server through AJAX. > - the server side would be - of course - written in Python. > > I was looking these projects: > > http://www.uize.com/http://pyjs.org/ > > There are many frameworks listed here which I did not > check:http://internetmindmap.com/javascript_frameworks. I have no idea which > has Python support, and probably there are only a few that worth looking > at. I wonder if you could tell me which are the pros and contras for > these frameworks. If there is a comparison available on the NET, > pointing me to the right URL would help a lot. > > The bottom line... > > My main goal is to develop enterprise class OLTP database applications. > I'll need grid widget to display data in tabular format, and I'll use > events heavily for data manipulation, live search, tooltips etc. I'm > familiar with wxWidgets, pygtk and other toolkits, but not with AJAX. I > have never used a system like that. pyjamas is, despite having a browser-based option, about as far away from "web" development as you can possibly get, with only the lack of access to "standard" python libraries and having to work with python reimplementations of math.py, re.py, time.py etc. being the stark reminder that you're reaallly not in kansas. the only thing that you have to get used to is that communication with the external world is done through HTTPRequest.py and, typically, its derivative, JSONService.py - even in the desktop version of pyjamas. but, if you're used to event-driven desktop environments such as wxWidgets and pygtk then the asynchronous nature of JSONService won't be a problem for you. i recommend that if you intend to develop an enterprise-style CRUD (create-retrieve-update-delete) application, that you take a look at the PureMVC-based examples: http://pyjs.org/examples/ search for "employeeadmin" and "timesheet". kees bos joined the project a few months ago, and his very first task that he set himself was to improve the pyjs compiler to the point where http://puremvc.org's python library could be used *unmodified* in pyjamas applications. he then set about porting (and bug-fixing!) the two wxWidgets python-puremvc examples to use pyjamas widgets. these two examples should give you a big head-start on what you want to achieve. if you are stuck on "pure javascript" frameworks, however, and you need "widgets", then there is one that i can tentatively recommend (with some trepidation, due to its enooormous size): extjs [no don't even _think_ of trying to combine it with pyjamas] and the other one is qooxdoo which is veery easy and intuitive, and well-designed. i don't honestly know if qooxdoo has a grid widget, but extjs most certainly does (and then some). the only issue with extjs is the sheer number of options and the whopping great size. whichever option you pick, you're basically in for quite a bit of learning, to get "started". if you pick pyjamas and you post on the pyjamas-dev list _please_ do remember to follow the rules about providing full context and a worked example if it's a programming issue, to help save people time, ok? :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: recommendation for webapp testing?
On Sep 17, 8:19 am, Simon Brunning wrote: > 2009/9/17 Schif Schaf : > > > What's the difference between WebDriver and Selenium? > > Selenium runs in a browser, and usesJavaScriptto perform all your > automated actions. It need a browser running to work. Several are > supported, Firefox, Safari, IE and I think others. You are at thier > mercy of the browser'sJavaScriptengine - I've often had trouble with > IE's XPath support, for instance - tests will run fine in Firefox and > safari, but not work in IE. > > One big advantage of Selenium is that there an "IDE" available, a > Firefox add-on which will allow you to record actions. This is useful > for building regression tests and acceptance tests for bugs. Sadly, it > often tempts people into writing their acceptance tests after the > fact, too - a grave mistake IMHO. > > Selenium tests can be written in Python, Ruby, Java, and in the form > of HTML tables. This last seems quite popular with QAs for some reason > which escapes me entirely. > > WebDriver runs outside a browser. It can be (and usually is) used to > drive a real browser, though there's is a HtmlUnit driver available, > which bypasses any real browser and goes direct to the site you are > testing. Even this last option, though, does allow the testing of > sites which make use ofJavaScript- which is just about all of them > these days. > > It makes use of native drivers for each of the browsers it supports, > so it runs very much faster than Selenium. Since it presents the test > program with its own version of the page's DOM tree, it's also less > likely to give browser incompatibilities. > > WebDriver tests can be written in Java or Python, at the moment. > > The Selenium people have recognized the superiority of the WebDriver > approach, so the nascent Selenium 2 will use WebDriver under the > covers. For the moment, though, you have to pick one or the other. > > Mechanize is a superb library for its intended purpose - I use it all > the time. It's lack of support for pages withJavaScript > functionality, though, means it's not very useful at a testing tool > for modern web sites. if you ask flier liu (http://code.google.com/p/pyv8) veeery nicely, he _might_ be persuaded to make the work he's doing be free software. hint: if you check closely into the pyv8 tests, you'll see a module "w3c.py" which implements DOM. in other words, he's writing a command-line-web-browser-without-the- gui-to-get-in-the-way. in other words, he's taking HTML off the web and _executing the javascript_ (using pyv8) to construct the exact same kind of page that a user would normally see _if_ you actually put the resultant DOM (after the javascript is done executing) into a web browser's display engine. the reason why he's doing is this is because he has quite literally miilllions of web pages to analyse, and working with e.g. selenium just absolutely does not cut the mustard, performance-wise. so, if you can get him to make the work he's doing free software, you will get a test suite whereby you can have pyv8 actually execute the on-page javascript, then use e.g. BeautifulSoup to walk the resultant DOM, and can do proper analysis of the DOM, which would otherwise be impossible. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas pyv8run converts python to javascript, executes under command-line
On Sep 20, 12:05 am, exar...@twistedmatrix.com wrote: > Does pyjamas convert any Python program into a JavaScript program with > the same behavior? that's one of the sub-goals of the pyjamas project, yes. > I don't intend to imply that it doesn't - I haven't > been keeping up with pyjamas development, so I have no idea idea. I > think that the case *used* to be (perhaps a year or more ago) that > pyjamas only operated on a fairly limited subset of Python. If this was > the case but has since changed, it might explain why some people are > confused to hear pyjamas called a Python implementation now. yup. "-O" now equals [roughly] pyjamas 0.3 to 0.5p1 behaviour, aka "pythonscript" - a mishmash of python grammar/syntax with javascriptic execution. since kees joined, he's been steaming ahead with python interoperability (--strict option). he first started out by improving the pyjamas compiler and support libraries to the point where the python version of http://puremvc.org could be compiled to javascript as-is, and it's gone from there, really. on the roadmap is to take a look at what the unladen/swallow team have done, when they get to their stage 2 "unboxing", and see if calling out to PyV8 or Python-SpiderMonkey objects can be done from intobject.c, longobject.c etc. if the early experiments are anything to go by, python will then have _yet another_ python accelerator. but, really, for that to properly happen, python has _got_ to get some type-checking decorators on functions: @paramtypecheck(foo=int, bar=[int, str]) @paramtypecheck(int, [int, str]) # or this @returntypecheck(int) def randomfunction(foo, bar): if isinstance(bar, str): bar = int(bar) return foo + bar this kind of type-checking guidance would _drastically_ help out all of the compilers (such as that python-to-c++ one), and could probably also be utilised by http://python.org itself, ultimately, to speed up function execution. it's also just good software engineering practice to check parameters and return results. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: pyjamas pyv8run converts python to javascript, executes under command-line
On Sep 19, 8:36 pm, Daniel Fetchinson wrote: > >> the pyjamas project is taking a slightly different approach to achieve > >> this same goal: beat the stuffing out of the pyjamas compiler, rather > >> than hand-write such large sections of code in pure javascript, and > >> double-run regression tests (once as python, second time converted to > >> javascript under pyv8run, d8 or spidermonkey). > > >> anyway, just thought there might be people who would be intrigued (or > >> horrified enough to care what's being done in the name of computer > >> science) by either of these projects. > > > I've added pyjamas to the implementations page on the Python Wiki in > > the compilers section: > > >http://wiki.python.org/moin/implementation > > In what way is pyjamas a python implementation? As far as I know > pyjamas is an application written in python that is capable of > generating javascript code. it's strictly speaking, according to wikipedia, a "language translator". i'm just in the process of adding an AST parser (based on lib2to3, from sgraham's work in skulpt) which will become the basis of an "exec" function, just like in the skulpt demo. also to answer your question: pyjamas has [roughly] two modes: -O and --strict. "-O" is the one where you have to write in a subset of python, and you can (unfortunately) do things like 5 + "px" (which doesn't throw an exception). this saves _vast_ amounts of CPU cycles. "--strict" as you would expect is the python-strict converter, where we're beginning to add implementations of __add__ etc. etc. and generally cope with the nasty grungy bits of javascript that would otherwise make arbitrary python applications keel over. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: can python make web applications?
On Sep 16, 7:02 pm, Paul Boddie wrote: > On 16 Sep, 18:31, lkcl wrote: > > > > >http://pyjs.org/examples/timesheet/output/TimeSheet.html > > I get this error dialogue message when visiting the above page: > > "TimeSheet undefined list assignment index out of range" > > Along with the following in-page error, once the data has been > imported: > > "JavaScript Error: uncaught exception: list assignment index out of > range at line number 0. Please inform webmaster." > > It looks quite nice, though. > > Paul DOH! someone assuming javascript-isms in lists, and the compiler's been improved to ban them :) ... self.date = None ... ... print 'setEntries:', entries try: #tt = time.localtime(time.time()) -tt = [] -tt[0] = int(self.date[:4]) -tt[1] = int(self.date[4:6]) -tt[2] = int(self.date[6:8]) +tt = [0] * 9 +if self.date: +tt[0] = int(self.date[:4]) +tt[1] = int(self.date[4:6]) +tt[2] = int(self.date[6:8]) tt[3] = 0 tt[4] = 0 tt[5] = 0 -- http://mail.python.org/mailman/listinfo/python-list
Re: can python make web applications?
On Sep 16, 7:02 pm, Paul Boddie wrote: > On 16 Sep, 18:31, lkcl wrote: > > > > >http://pyjs.org/examples/timesheet/output/TimeSheet.html > > I get this error dialogue message when visiting the above page: > > "TimeSheet undefined list assignment index out of range" ah well spotted, thanks paul. -- http://mail.python.org/mailman/listinfo/python-list
[ANN] pyjamas pyv8run converts python to javascript, executes under command-line
just for fits and giggles and also because i'm getting fed up of using web browsers as part of the pyjs development cycle instead of the command-line, the pyjamas pyv8run.py has been brought back up-to- scratch, and can now execute the pyjamas LibTest regression tests with a 99.95% pass rate. pyv8run is a back-to-back combination of google's v8 engine + a library by flier liu which makes extensive use of python-boost (http:// code.google.com/p/pyv8) + the pyjamas python-to-javascript compiler. the initial experiment some months ago, with pyjamas 0.5, produced a python ACcellerator with a 10x performance increase; the latest 0.6~svn pyjamas compiler results in a python DEcellerator with a [finger-in-the-air] 10x performance DEcrease, thanks to the addition of several python strictness features. hurrah! :) perhaps it is the fact that the 0.5 test used google's stable x86 libv8, and the 0.6~svn test used google's alpha-release of amd64 libv8 - who knows, who cares, it's just hilarious to convert arbitrary python code into javascript and have it do 99.95% the same job. on the roadmap of this sub-sub-project of pyjamas is: * to throw pyv8run at the standard http://python.org regression tests and see what sticks * to improve the pyjamas compiler and/or alter the adapted lib2to3 parser/AST library in order to create a stand-alone, self-bootstrapped _javascript_ version of the pyjamas python-to-javascript compiler. this is _mandatory_ in order to support "eval" and "exec" - execution of python _source_ code - inside web browsers (and under a js> prompt such as spidermonkey or d8) this latter goal has already been hilariously achieved by the (completely independent) skulpt project: http://skulpt.org/ whose parser/AST code the pyjamas project has borrowed - and back-ported from javascript to python. you can see their demo python prompt on the main page, and use it to mash your own web browser of choice into submission. the pyjamas project is taking a slightly different approach to achieve this same goal: beat the stuffing out of the pyjamas compiler, rather than hand-write such large sections of code in pure javascript, and double-run regression tests (once as python, second time converted to javascript under pyv8run, d8 or spidermonkey). anyway, just thought there might be people who would be intrigued (or horrified enough to care what's being done in the name of computer science) by either of these projects. l. -- http://mail.python.org/mailman/listinfo/python-list
