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: 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: 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 [email protected]: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: 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: Framework for a beginner
On Apr 11, 9:11 pm, [email protected] 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
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: 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: Python for Web
On Jun 15, 1:11 pm, "[email protected]" 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: 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: 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: 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: 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 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, 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 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
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 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
Re: Mod_python, jsonrpc and sessions
On Jan 14, 4:47 pm, [email protected] wrote: > Hi, > > I've got a python web-application being served by apache via > mod_python, in which the users sessions are tracked via the mod_python > Session module. > Some of websites generated contain a java-script function which starts > a jsonrpc call to the same server and gets further data or stores > something to a database (AJAX). The server-sided jsonrpc functions are > written in python as ServiceMethods. > > As I need to identify the user issuing the rpc call, I'm wondering if > there is any possibility to access the session created by the > previosly called mod_python Handler-method. In mod_python it is > accessed using the mod_python request object, but in the rpc > servicemethod I don't have such an object. So how can I track the rpc > caller? the only way to store "session" info reliably is: cookies. therefore, the code in one part of the application _will_ have to store a session cookie as an identifier, and you can track the name of that cookie through the source code that created it. or look in the source code for anything beginning with the word "session". "grep - ril" is your friend. also, if the app stores its session authentication information in a database, you can look through the app for the database table name. if you don't _know_ the database table name, and are having difficulty finding out because the design of the app is SHITE then you can do a dump of the database _before_ a session login, and a dump afterwards, and then diff is your friend. if the database is mysql, add --extended-insert=no (something like that) to the mysqldump command otherwise you will have a bitch-awful job identifying the right line. i've done this when working with fricking-joomla, integrating it with django. fireboard. i had to hunt through the php code looking for the database user-session. once you have the session info, that's your "user tracking" function in the rpc calls. none of the above is particularly rocket science - or actually anything to do with python: it's a simple matter of applying investigative techniques logically working from how the technology _should_ work and then bludgeoning it into submission to tell you what the hell's going on. l. -- http://mail.python.org/mailman/listinfo/python-list
Applying a decorator to a module
Very simple question: how do you apply a decorator to an entire module? an idea whose time has properly arrived is to merge pyjamas (http://pyjs.org) into web2py (http://web2py.com), and to do that, it's necessary to "identify" functions, classes, global variables and modules that should be compiled into javascript, rather than executed server-side. i figured that the best pythonic way would be to put a decorator on an entire module, if the entire module was to be compiled to javascript. ... however, i don't know how to do that! @decorate(module) ? @decorator() import modulename ? should this work? many thanks, l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Applying a decorator to a module
On Nov 27, 7:43 pm, [EMAIL PROTECTED] wrote: > lkcl> Very simple question: how do you apply a decorator to an entire > lkcl> module? > > Function-by-function or class-by-class. There is no decorator support for > modules. awWww! i'm going to quietly throw my toys out of my pram. ... but seriously - doesn't that strike people as... a slightly odd omission? l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python+Pyjamas+V8=ftw
> Another project similar-ish to Pyjamas is > HotRuby:http://hotruby.yukoba.jp/ also there's RubyJS: http://rubyforge.org/projects/rubyjs/ it's again a javascript compiler - ruby to javascript - and the beginnings of a port of GWT to Ruby, called rwt. this project _definitely_ needs more attention. michael's talk (included in the docs/) shows that he has spent considerable effort in ensuring that not only is the compiler faithful to the features of ruby, but also that the features are translated _efficiently_. which takes a hell of a lot of doing. the nice thing about michael's work is that he's leading the way in showing the pyjamas compiler how it _really_ should be done. pyjamas is capable of running a very significant amount of python, but it _is_ missing some crucial features: **kwargs for example, and the 0.4 release has just added a _very_ basic type of exception handling. that having been said: for the majority of purposes - most web development - pyjamas is _more_ than adequate. as a general-purpose plugin replacement for /usr/bin/python, however, it's not quite there. and, given that javascript cheerfully goes about its way with the "undefined" concept, it's always going to be a _bit_ tricky to provide absolutely _every_ language feature, faithfully. that having been said, the speedup factor of pyv8 should make the pyjamas compiler a _really_ attractive option, and i think that when it becomes the "norm" to have a javascript interpreter as part of a sysadmin's / developer's dailiy life in the same way that /usr/bin/ perl and /usr/bin/python are, then compilers like RubyJS, Pyjamas and GWT will have a much bigger significance. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pyjamas 0.4: Python Web Toolkit Release
On Dec 2, 6:52 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]> wrote: > > >Pyjamasstarted as a port of Google's Web Toolkit, to python. > > Explaining whyPyjamas(and GWT) is so significant takes > > some doing: the summary is that comprehensive desktop-like > > user interfaces can be developed very simply, to run in > > any modern web browser, without having to write a single > > line of JavaScript. > > Great concept. 's'wikkid :) > The demos are a bit flakey (especially with IE): ehn? o dear. well, i try my best with ies4linux (ie6 under wine). ie7 doesn't qute cut it, and the script debugger just doesn't quite want to play nice under wine. so if you do make a report, please _do_ make sure it includes a full stack trace, not just a line number. > where do you want bug > reports (the sourceforge tracker seems to be empty so I wondered if you > used somewhere else)? code.google.com - http://code.google.com/p/pyjamas/issues/list thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating an application for Linux
hiya mike: where do i know you from? i've heard your name somewhere and for the life of me can't remember where! anyway... onwards. your simplest bet is to take advantage of the .deb install system, which, if you follow that, will allow you to pull in all of the dependencies _without_ screwing around with the ubuntu distribution, or requiring that you build "special" versions of the dependencies. so - your first port of call is to locate a similar app to your own one: apt-cache search wxwidgets [rose-tinted filter on the results...] cryptonit - A client side PKI (X.509) cryptographic tool fontypython - A GUI tool to manage ttf fonts jmdlx - jugglemaster deluxe using wxWidgets wxmaxima - a wxWidgets GUI for the computer algebra system maxima multiget - graphical download manager then, do apt-cache show , paying particular attention to the dependencies. apt-cache show fontypython looks like a good candidate. so, do apt-get source fontypython (or other candidate) also do apt-get build-essential dh-make dpkg-dev debutils python-dev devscripts python-setuptools juuust for fun, but the essential ones are probably dh-make and dpkg-dev. then you have something to work from (an example - the source of the deb-wrapped fontypython) and you will have most of the debian developer utils etc. etc. _then_ you go to e.g. this: http://www.pythonmark.com/python-library/debian/howto-build-a-debian-package-from-python-sources/ the preamble for which says "don't bother with that annoying ubuntu python deb howto video, particularly on the basis that who gives a stuff about _verbal_ instructions when you actually want stuff you can READ!" :) the most important thing that _you_ need to remember is that you _must_ identify the correct libraries (and their debian packagenames - can't bring myself to say ubuntu packagenames) and make damn sure that you add them into the dependencies in the debian/control file. do _not_ be tempted to "bundle" customised versions of python- pysqlite, python-sqlalchemy etc. etc. testing: you should really use a debootstrap absolute "basic" environment (set up a chroot, or a virtual KVM or other virtual PC, qemu, whatever, or even a real machine) do NOT do a "full" install of ubuntu, do an absolute minimalist install (netbook, businesscard, whatever). ... and _then_ install your .deb (with dpkg -i) followed by apt-get -f install (to pull in all of the dependencies). then, use export DISPLAY=192.168.1.5:0.0 (adapt as necessary), run xhost + on 192.168.1.5 (adapt as necessary), and _then_ fire up your test app. if you get a python library not found runtime error, you know that you got your dependencies wrong, in the debian/control file. if you install a "vanilla" ubuntu desktop, various other packages will pull in the dependencies for you - and you will never find out if you got all of the dependencies correct. that having been said, if you don't _care_ about correctness, skip the above six sentences :) l. On Dec 31, 9:06 pm, Mike Driscoll wrote: > Hi, > > My boss wants me to port one of my applications to Ubuntu. I > successfully ported it without too many headaches but now I need a way > to distribute it to people that may or may not already have the > dependencies my application requires. I'm a newb with Linux so I'm not > even sure what they call the distribution (rpms, deb, source code). > > After browsing the various "installer" docs out there, it looks like > bbfreeze or PyInstaller might work, but I couldn't find any examples. > Any advice is appreciated. Thanks! > > I am using Python 2.5.2 and this is a wxPython application with > SqlAlchemy and a few other external packages. > > Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating an application for Linux
On Dec 31 2008, 9:54 pm, Mike Driscoll wrote: > On Dec 31, 3:36 pm,lkcl wrote: > > > hiya mike: where do i know you from? i've heard your name somewhere > > and for the life of me can't remember where! anyway... onwards. > > I don't know...while your username looks vaguely familiar, I don't > think I've communicated with you recently. I spend most of my time on > the wxPython list now... i think it might be from my old school - i could be confusing you with someone, though - "gary driscoll", perhaps? anyway, never mind :) > > testing: you should really use a debootstrap absolute "basic" > > environment (set up a chroot, or a virtual KVM or other virtual PC, > > qemu, whatever, or even a real machine) do NOT do a "full" install of > > ubuntu, do an absolute minimalist install (netbook, businesscard, > > whatever). > > I thought the general practice was to test on the closest software/ > hardware combo that your application was most likely to run on. that you should do as well :) you should be able to either upgrade the bare-bones version using "tasksel install desktop" or just... what-the-heck, install on a vanilla combo. http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-i386/current/images/netboot/ archive.ubuntu.com appears offline at the moment - maybe it'll be back later. i recommend you go for the mini.iso > I have > heard of doing testing on the lowest common denominator before though. > Unfortunately, I don't have time to set up a bare-bones VM since we're > closing soon, but I may give this a go on Friday and report back. ok - the issue that you will face if you _don't_ do a LCD test is that should ubuntu get upgraded, and one of the packages that _used_ to pull in a dependency [that you missed] no longer does so... -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating an application for Linux
On Jan 1, 4:44 pm, Mike Driscoll wrote: > On Jan 1, 7:47 am,lkcl wrote: > > > > > On Dec 31 2008, 9:54 pm, Mike Driscoll wrote: > > > > On Dec 31, 3:36 pm,lkcl wrote: > > > > > hiya mike: where do i know you from? i've heard your name somewhere > > > > and for the life of me can't remember where! anyway... onwards. > > > > I don't know...while your username looks vaguely familiar, I don't > > > think I've communicated with you recently. I spend most of my time on > > > the wxPython list now... > > > i think it might be from my old school - i could be confusing you > > with > > someone, though - "gary driscoll", perhaps? anyway, never mind :) > > > > > testing: you should really use a debootstrap absolute "basic" > > > > environment (set up a chroot, or a virtual KVM or other virtual PC, > > > > qemu, whatever, or even a real machine) do NOT do a "full" install of > > > > ubuntu, do an absolute minimalist install (netbook, businesscard, > > > > whatever). > > > > I thought the general practice was to test on the closest software/ > > > hardware combo that your application was most likely to run on. > > > that you should do as well :) you should be able to either upgrade > > the bare-bones version using "tasksel install desktop" or just... > > what-the-heck, install on a vanilla combo. > > > http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-i386/c... > > > archive.ubuntu.com appears offline at the moment - maybe it'll be > > back later. i recommend you go for the mini.iso > > Ok...thanks for the info! > > > > I have > > > heard of doing testing on the lowest common denominator before though. > > > Unfortunately, I don't have time to set up a bare-bones VM since we're > > > closing soon, but I may give this a go on Friday and report back. > > > ok - the issue that you will face if you _don't_ do a LCD test is > > that > > should ubuntu get upgraded, and one of the packages that _used_ to > > pull > > in a dependency [that you missed] no longer does so... > > I see. I had hoped that there was a way to create a frozen application > like I do with py2exe on Windows so I wouldn't have to worry about a > Linux upgrade breaking my application. I've been told that ok - to do _that_, you will have to download copies of every single library that your app uses, compile them specially into a customised location (/opt/local or /usr/local); you will have to then make sure that PYTHONPATH environment variable is set to point to the locations. from a random manual somewhere: The PYTHONPATH variable can be set to a list of paths that will be added to the beginning of sys.path. For example, if PYTHONPATH is set to "/www/python:/opt/py", the search path will begin with ['/www/ python', '/opt/py']. (Note that directories must exist in order to be added to sys.path; the site module removes paths that don't exist.) having multiple copies of python libraries on your system was exactly the thing that i recommended that you _not_ do :) because you _still_ have to install them, and the process to do _that_ easily, on ubuntu, is "apt-get install" - so why bother duplicating that effort? path of least resistance says "go with the debian flow". well... it does in my book, anyway :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling python2.5 on linux under wine
> ... nd, that means disabling setup.py or hacking it significantly > to support a win32 build, e.g. to build pyexpat, detect which modules > are left, etc. by examining the remaining vcproj files in PCbuild. > > ok - i'm done for now. > if anyone wants to play with this further, source is here: > >http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine patch is also here: http://bugs.python.org/issue4880 -- http://mail.python.org/mailman/listinfo/python-list
Re: compiling python2.5 on linux under wine
> ... nd, that means disabling setup.py or hacking it significantly > to support a win32 build, e.g. to build pyexpat, detect which modules > are left, etc. by examining the remaining vcproj files in PCbuild. ok - i started the hacking. the first bit of hacking is this, in distutils/sysconfig.py, added to _init_nt() try: filename = get_makefile_filename() parse_makefile(filename, g) except IOError, msg: my_msg = "invalid Python installation: unable to open %s" % filename if hasattr(msg, "strerror"): my_msg = my_msg + " (%s)" % msg.strerror raise DistutilsPlatformError(my_msg) # load the installed pyconfig.h: try: prefix = EXEC_PREFIX prefix = os.path.join(prefix, "PC") filename = os.path.join(prefix, "pyconfig.h") parse_config_h(file(filename), g) except IOError, msg: my_msg = "invalid Python installation: unable to open %s" % filename if hasattr(msg, "strerror"): my_msg = my_msg + " (%s)" % msg.strerror raise DistutilsPlatformError(my_msg) global _config_vars _config_vars = g that gets me part-way - at least i get... oh dear : self.build_extensions() File "../setup.py", line 183, in build_extensions self.compiler.set_executables(**args) File "Z:\mnt\src\python2.5-2.5.2\lib\distutils\ccompiler.py", line 165, in set_executables (key, self.__class__.__name__) ValueError: unknown executable 'compiler_so' for class MSVCCompiler whoops :) so, next, we hack in a compiler, in to ... ooo, let's saaay... distutils/cygwinccompiler.py, just for fun. now we get this! winegcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall - Wstrict-prototypes -I. -IZ:\mnt\src\python2.5-2.5.2\./Include -I. - IInclude -I../Include -I/usr/local/include -IZ:\mnt\src \python2.5-2.5.2\include -IZ:\mnt\src\python2.5-2.5.2\PC -c Z:\mnt\src \python2.5-2.5.2\Modules\_ctypes/_ctypes_test.c -o z:\mnt\src \python2.5-2.5.2\modules\_ctypes\_ctypes_test.o wha-hey! but... oh dear. oh dear number 1) firstly, err this is cross-compiling - those path names are bullshit because actually we're compiling on LINUX damnit, not windows. hmm there's something to work around that one, perhaps, by installing the mingw32 compiler under wine (o god i've done that before, it's dreadfully slow) oh dear number 2) File "Z:\mnt\src\python2.5-2.5.2\lib\os.py", line 562, in spawnv return _spawnvef(mode, file, args, None, execv) File "Z:\mnt\src\python2.5-2.5.2\lib\os.py", line 545, in _spawnvef wpid, sts = waitpid(pid, 0) NameError: global name 'waitpid' is not defined err oh - ok, found another missing function: spawnv. so, added that, in PC/pcbuild.h: #ifdef __WINE__ #define HAVE_SPAWNV #endif and after some futzing around with yet more #ifdefs in posixmodule.c we have another build - this time using wine's spawnv so it doesn't try to find a non-existent waitpid aaannnd SPLAT yesss, we get the crash-output from winegcc: Failed to configure _ctypes module building '_ctypes_test' extension winegcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall - Wstrict-prototypes -I. -IZ:\mnt\src\python2.5-2.5.2\./Include -I. - IInclude -I../Include -I/usr/local/include -IZ:\mnt\src \python2.5-2.5.2\include -IZ:\mnt\src\python2.5-2.5.2\PC -c Z:\mnt\src \python2.5-2.5.2\Modules\_ctypes/_ctypes_test.c -o z:\mnt\src \python2.5-2.5.2\modules\_ctypes\_ctypes_test.o wine: Unhandled page fault on read access to 0x7265704f at address 0x601ec25b (thread 001c), starting debugger... Unhandled exception: page fault on read access to 0x7265704f in 32-bit code (0x601ec25b). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:601ec25b ESP:0032c70c EBP:0032c718 EFLAGS:00010206( - 00 - RIP1) EAX:7265704f EBX:7bc8a7a4 ECX:0003 EDX:604ab3d7 ESI:0032c848 EDI:7265704f Stack dump: 0x0032c70c: 7bc6859d 7265704f 6056a0b8 0032c788 0x0032c71c: 603fd0eb 7265704f 006e9544 001bc84c 0x0032c72c: 006c574c 6056b82c 605721a0 0002 0x0032c73c: 0032c7d8 718e21fe 0016329c 7265704f 0x0032c74c: 00730065 002e0074 006f 00159320 0x0032c75c: 603aa590 001b3f0c 005086e0 0004 Backtrace: =>1 0x601ec25b strlen+0xb() in libc.so.6 (0x0032c718) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value degToRad (a) 2 0x603fd0eb do_mkvalue+0x3db(p_format=, p_va=, flags=0x0) [/mnt/src/python2.5-2.5.2/ build/../Python/modsupport.c:419] in python (0x0032c788) 3 0x603fcc6d do_mktuple+0x7d(p_format=0x32c848, p_va=0x32c844, endchar=0x29, n=0x2, flags=0x0) [/mnt/src/python2.5-2.5.2/build/../ Python/modsupport.c:268] in python (0x0032c7b8) . . hey, this is fun! let's try a crazed compile of python and see what falls over, whe :) ... much as this seems to be consuming much of my time, for some bizarre reason i just can't seem to stop. anyway - yes, this is effectively cross-compiling, and so the python25.exe and en
Re: component / event based web framework for python?
On Sep 15, 4:53 pm, Jaime Barciela <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've been surveying the field ofpythonweb frameworks for a while but
> there are just too many so I ask mighty Usenet.
>
> Is there a component / event based web framework forpython? Something
> that can abstract you from the request/response mechanism and ideally
> from html and javascript altogether?
yep. Pyjamas. http://pyjs.org
in fact, it's _so_ abstracted from html and javascript that i ported
pyjamas to the desktop, using python bindings to glib bindings to
webkit - see http://webkit.org or better:
http://pyjd.org
> As examples -- in other languages -- of what I have in mind:
> - in java: wingS,GWT, echo (2,3), karora, thinwire, itmill,
Pyjamas is a port of GWT to python.
> I would like to be able to write code equivalent to this C# example:
>
>
> namespace WebApplication1
> {
> public partial class _Default : System.Web.UI.Page
> {
> protected void Page_Load(object sender, EventArgs e)
> {
> Button b = new Button();
> b.Text = "say hello";
> b.Click += Button1_Click;
> Panel1.Controls.Add(b);
> }
>
> protected void Button1_Click(object sender, EventArgs e)
> {
> Label1.Text = "Hello dynamically created on the fly
> UI !!!";
> }
> }}
how about this:
from pyjamas import Window
from pyjamas.ui import Button, RootPanel
def greet(sender):
Window.alert("Hello, AJAX!")
class Hello:
def onModuleLoad(self):
b = Button("Click me", greet)
RootPanel().add(b)
is that close enough? :) does it look _remotely_ like javascript,
html, or even like it's web programming? doesn't it remind you of
pygtk2 rather a lot? :)
more working examples at http://pyjs.org/examples/
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> 3) Following the public rumor mill and the latest hype RIA i.e. the > merge of web- and desktop applications with systems like Adobe AIR, > JavaFX, Google Gears and MS Silverlight is the future of frontend > development. With the exception of IronPython and Silverlight, Python > hasn't even entered this game and no one knows if it ever will. http://pyjd.org tada :) (based on webkit, just like adobe air is). -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> The role of Python is somewhat arbitrary. This could change only if > Python becomes a client side language executed by AVM, V8 etc. pyv8 - http://advogato.org/article/985.html pyjs.py - standalone python-to-javascript compiler, see http://pyjs.org. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Sep 17, 1:16 am, Todd Whiteman <[EMAIL PROTECTED]> wrote: > Todd Whiteman wrote: > > Mark Hammond's Python/Mozilla work has enabled products like Komodo, > > Miro (Democracy) and the OLPC project to use Python as a major driver > > for consistent cross-platform GUI applications. > > > Personally, I believe XULRunner has a lot to offer for Python GUI > > development, I'm currently finishing up some documentation steps to show > > off how to use it specifically for Python (I'll post it to this list > > when it's finished). > > Here is the tutorial I've started in order to show off building a > Python/XULRunner GUI > application.http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xul... > > The details in this tutorial mostly targets a Windows/Linux platform > (MacOSX is possible with a few deviations, I have tried to cover these > deviations where applicable). > > Feedback is welcome. oh for _goodness_ sake :) i don't know whether to be derangedly-happy and overexcited that pyxpcom and pydom exist, or whether to be annoyed that i'll have to do _yet another_ port of the pyjamas widget set api to another platform. how come this stuff is so hard to find? it's a _brilliant_ idea to be running python in a web browser, direct. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Sep 3, 4:34 pm, Michael Palmer <[EMAIL PROTECTED]> wrote: > So far, development of PyGUI seems to be a one-man effort, and it may > be slowed down by the attempt to develop the API and the > implementations concurrently. Could it be useful to uncouple the two, > such that the API would be specified ahead of the implementation? michael, i went back to the beginning of this thread, to reply to your question, because i have some insights to share with you from my failed attempts on porting pyjamas to the desktop - which you can collect here: http://lkcl.net/pyjamas-desktop there, you will find an IronPython-GtkSharp port; a pyqt4 port and a pygtk2 port. they were each failures in their own unique and special ways. to explain: pyjamas is a widget set api that looks desktop-like; you write code in python, it's compiled to javascript; the DOM.py module actually does things like document.getElementById() etc. etc. and in this way you end up completely manipulating the DOM model, turning the browser into just a giant desktop-like canvas. in fact, the pyjamas widget set api is _so_ similar to a desktop api that i decided to have a go at porting it _to_ the desktop. eventually i succeeded. the first attempt was with ironpython. i actually got a long way with this one - i chewed through the pyjamas examples in about a day. i had a small stumbling block implementing the HTML() widget, but GtkSharp.HTML came to the rescue, there, and i was off again. i then ran into a wall i decided not to bash my head against at such an early stage (36 hours) - an implementation of XMLHTTPRequest (remember - i was implementing every single bit of functionality that a DOM model has access to). so, i decided to port the ironpython port to pygtk2. unfortunately, whilst i got a lot further and managed to implement all of the examples, there was no equivalent of HTML(). GTK itself totally lacks a rich media content widget. there is python-gtkhtml2 which is good, but not good enough. the much better gtkhtml3 library doesn't have python bindings around it, and i wasn't in the mood to write any (and hadn't at the time any experience with pygtk codegen.py). also i heard that gtkhtml2 had been abandoned, and gtkhtml3 wasn't going to be followed up on, and that there were rumours about webkit. crucially - much more importantly - gtkhtml 2 and 3 have absolutely no "automatic" resizing of the HTML content within them. so, unless you specify both the width and the height of the widget container, you end up with a flatlined widget. by that i mean a widget of say 200 pixels in width but ZERO pixels in height! and, as you may well know, if you specify a width and height on a gtk widget, that's it: it's entirely fixed. there's no going back. you're screwed. this was an absolute killer. with no foresight in the design of gtk or gtkhtml2 to make even a _guess_ at the width and height of the content, the port was screwed. i made half-hearted attempts to not specify width/height at all, but all that that resulted in was piss-poor layout, and when you shrank the app to small size, all the text disappeared because there was a margin defaulting to 5px or so and all but the top left corner of the text boxes would disappear! so, there was no point in me attempting to make python bindings around gtkhtml3, even though it has a system for inserting widgets into HTML (using span ids). and, even though there's python-gtkmozembed wrappers which would have allowed me to embed flash plugins etc. into my application, thus neatly emulating the way that html allows you to do that. so - sadly - on to pyqt4. well, i say sadly, but it was actually quite fun. i'm doing a complete comprehensive test of absolutely every single feature of the major widget sets out there, crawling every single corner of their functionality in order to map concepts one-for-one, and finding that they don't really cope. pyqt4. again, i got a long long way. the rich media support of qt4 allowed me to do widgets that looked reasonable. i even had, by that time, a non-asynchronous version of XMLHTTPRequest. then i got to the implementation of Grid() and FlexTable(). this is where it started to go wrong. pyqt4 has the concept of layouts. a layout can be a horizontal layout, vertical, grid, and you can even specify the percentage or ratio of the width (or height) that individual cells can use. you attach a layout to a widget; you can attach layouts to layouts. you can remove layouts from widgets. what you _can't_ do is _remove_ layouts from layouts. disappointingly, this was the killer, for me. it was just getting... too complicated. i had already encountered advice that, in order to implement the means to move widgets around, i should remove *everything* and redo the layout. it just... wasn't happening. plus, i think also that there are problems, again, with the HTML layout: you can't _entirely_ stop text-squashing. so, although pyqt4 was _better_, it sti
Re: PyGUI as a standard GUI API for Python?
On Oct 11, 3:31 pm, David Boddie <[EMAIL PROTECTED]> wrote: > On Saturday 11 October 2008 11:19, lkcl wrote: > > > pyqt4 has the concept of layouts. a layout can be a horizontal > > layout, vertical, grid, and you can even specify the percentage or > > ratio of the width (or height) that individual cells can use. you > > attach a layout to a widget; you can attach layouts to layouts. you > > can remove layouts from widgets. what you _can't_ do is _remove_ > > layouts from layouts. > > You can remove layouts from layouts with the QLayout.removeItem() method. yes... it didn't work. a layout within a layout - i think it was a QHorizontalLayout within a QGridLayout - didn't want to be removed. it's probably a bug. > These days, you'd probably use PyQt4's WebKit integration for HTML > rendering, anyway, though I imagine that it doesn't help you much if > you're already using WebKit directly. [see below...] > You can write your own layouts as well, but maybe that's more work than > you're prepared to do, definitely. > especially now that you seem to have settled on > WebKit as your toolkit. well, it just made vast amounts of sense - cut out all the middle men. if you're going to pull in a 17mb binary dependency, why do it in a clumsy way? in order to pull in flash plugins and other material, the accepted method in pygtk2 is to use python-gtk-mozplugger. that's crazy. embed an _entire_ web browser, just to pull in a flash component. likewise, for doing a single bit of HTML, in pyqt4 and/or pygtk2, pull in a 17mb binary dependency using python-webkit-qt4 and/or pywebkitgtk, _just_ to display _one_ bit of HTML text?? _that's_ crazy. especially as webkit actually has far better rendering capability, features and flexibility than any of the standard desktop widget sets which had been designed for the job! wonderfully ironic... oh - for completeness, if anyone's reading this and goes "no chance i will _ever_ convert to the pyjamas API because i've spent so much time writing pygtk2 apps" - there is a project by luis pamirez, where he has _reimplemented_ gtk.py, gobject.py and gdk.py to sit _on top_ of the pyjamas DOM model. at present, it's only available in the subversion repository of http://code.google.com, and you'll need to check out a revision some time around sep 2007 of the llpamies branch. basically, what that will give you is a means to run your pygtk2 applications... in a web browser! very cool. i'll do a port to pyjamas-desktop at some time, if i have a need for it, and will be happy to help guide anyone who wants to spend the time on it themselves. > especially now that you seem to have settled on WebKit as your toolkit. well, it's not _my_ toolkit - i just use it. but you're right inasmuch as i won't be initiating any new applications using pyqt4 or pygtk2, not out of personal choice, anyway. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
ofhttp://code.google.com, and you'll need to check out a revision some > time around sep 2007 of the llpamies branch. rsrrmsrrwssrrfssnrssrr :) http://code.google.com/p/pyjamas then follow through to svn instructions, bearing in mind that, other than the llpamies branch, that code is out-of-date. -- http://mail.python.org/mailman/listinfo/python-list
Re: Safe eval of insecure strings containing Python data structures?
On Oct 9, 4:32 am, "James Mills" <[EMAIL PROTECTED]> wrote: > On Thu, Oct 9, 2008 at 2:26 PM, Warren DeLano <[EMAIL PROTECTED]> wrote: > > JSON rocks! Thanks everyone. > > Yes it does :) > > > Ben wrote: > > >>More generally, you should never execute (via eval, exec, or whatever) > >>*any* instruction from an untrusted path; especially not arbitrary > >>data from an input stream. rubbish. this is why a project i was involved with, to do execution of code from a database instead of a filesystem had to be abandoned, back in 2001. there are perfectly good systems for associating security context with "arbitrary data" (as the security models of SE/Linux, based on Flask, and the security model of windows nt, based on VAX/VMS security, show). there was a flawed design decision in python 2.2 or python 2.3 which resulted in an "escape route" - i believe it centered around either __class__ or __new__ - in the c code, which the developers had not considered, and would not correct. this decision resulted in the abandonment of the rexec.py module in python: you can see for yourself because it raises a runtime exception when you try to use it, issuing a warning. it's _perfectly_ possible to define security contexts and boundaries, and to allow access to functions and modules on a per-security-context basis. *as defined by the application developer* [not by the developers of python itself] if an individual developer wants to allow "arbitrary code execution from any data stream", it most certainly is _not_ anyone's place to dictate to them that they "cannot do this". instead, there should be a mechanism in place which allows them to choose which foot they want to lose with the loaded gun they're pointing. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 11, 11:17 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > lkcl wrote: > > I got the impression that there is currently no Windows binary > available. Correct? If not, perhaps someone trustworthy will someday > donate one. sorry, terry, you deleted a bit too much context :) so, assuming that you mean "that there is currently no http://pyjd.org windows binary", then then answer is: pyjamas-desktop is pure python, relying on a modified version of pywebkitgtk and a modified version of webkit to add glib bindings to it. i spent one week fighting with mingw32 to cross-compile webkit for win32 - when i say fighting i mean segfaults at link time (!!), which was tracked down to the msvc-compiled version of libicu 3.8 and eliminated by hack-compiling libicu with mingw32; _rebuilding_ mingw32 from the latest svn at the time, in order to include support for exceptions across thread boundaries (libstdc++ exceptions - libgcc_a.dll) all in all, it was a bitch :) _then_ i started on cross-compiling python2.5 because there's no .exe or .zip installer for python - only a .MSI, and, having installed MSI under wine on linux with the excellent "winetricks" script, it causes a segfault when you try to run a .MSI. cross-compilation of python2.4 was successful (by the person who did the initial patch, a year ago). cross-compilation of python2.5, to generate a libpython2.4.dll and .a, fails miserably. why the python developers didn't include the patches, and keep them up- to-date, isn't clear. at that point, i gave up, despite valiant efforts, because it was clear that, given that there was no financial incentive to continue, i was wasting my time. the bottom line is: if you want a windows version of pywebkitgtk, i'm happy to assist and advise anyone of the process- it should be quite straightforward _if_ you have MSVC and follow the standard procedure, but i'm not about to spend my own time and effort on providing a win32 port using ming32, doing all the work _myself_, on my own, without financial incentive and renumeration. i'll happily explain to other people what _they_ need to do, though. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib equivalent for HTTP requests
On Oct 8, 7:34 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > I would like to keep track of that but I realize that py does not have > > a JS engine. :( Anyone with ideas on how to track these items or yep. > What you can't do though is to get the requests that are issued > byJavascriptthat is *running*. yes you can. see recent post i made just a few minutes ago giving some insights into each of the available options. look up pyv8; pykhtml; spidermonkey; webkit with the python bindings to its glib bindings - pywebkitgtk - use my patched version and see http://pyjd.sf.net to get precompiled versions; pyxpcomext and pydom on developer.mozilla.org; webkit's DumpRenderTree with the --html option, to name but a few. there are _tons_ of options. they're just an absolute bastard to track down, because javascript is such a popular keyword to search for, the results are almost useless. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: parsing javascript
On Oct 12, 2:28 pm, Philip Semanchuk <[EMAIL PROTECTED]> wrote:
> On Oct 12, 2008, at 5:25 AM, S.SelvamSivawrote:
>
> > I have to do a parsing on webpagesand fetch urls.My problem is ,many
> > urls i
> > need to parse are dynamically loaded usingjavascriptfunction
> > (onload()).How to fetch those links from python? Thanks in advance.
>
> Selvam,
> You can try to find them yourself using string parsing, but that's
> difficult. The closer you want to get to "perfect" at finding URLs
> expressed in JS, the closer you'll get to rewriting a JS interpreter.
> For instance, this is not so hard to understand:
> "http://example.com/";
> but this is:
> "http://ZZZ_DOMAIN_ZZZ/index.html".replace(/ZZZ_DOMAIN_ZZZ/,
> the_domain_variable)
>
> This is a long-standing problem for any program that parses Web pages.
yep :)
> You either have to embed a JS interpreter in your application or
yep.
there are several.
pyv8 is the newest addition: http://advogato.org/article/985.html
it's a python wrapper around google's v8 javascript execution
library.
then there's pykhtml: http://paul.giannaros.org/pykhtml/
it's a python wrapper around KHTML, providing very convenient access
to KDE's HTML capabilities: what pykhtml does is "pretends" that the
GUI part of KDE doesn't exist, so you can run your program as a
command-line shell; it will execute the javascript, which you will
have to wait a bit for of course; then you can walk the DOM tree
(using pykhtml bindings) using pykhtml.DOM.getElementById() and
getElementsByTagName("a") etc. etc. looking for the URLs.
there's even an AJAX example included which does 1-second polling of
the DOM model, waiting for a spell-checking web site to deliver the
answer.
then there's webkit, with the new glib bindings:
https://bugs.webkit.org/show_bug.cgi?id=16401
which are then followed up by python bindings to _those_ bindings:
http://code.google.com/p/pywebkitgtk/issues/detail?id=13
this will also allow you to execute arbitrary javascript - again, it's
similar to KHTML and in fact webkit really _is_ the KDE KHTML code
(JavaScriptCore, KJS etc) but forked, improved, etc. etc.
unfortunately, the glib bindings are tied - at three key and strategic
locations - to gtk at the moment, which will take _very_ little work
to "un"tie them [pay me and i'll do the work], so you would need to
create a blank gtk window - just like is done with pykhtml, behind the
scenes.
it would be a very simple task to create a "dummy" - console-based -
port of webkit, providing an array of callbacks which you must hand to
the library. at the moment, the design of webkit is not particularly
good in this respect: there are three ports, gtk, wx and qt, which are
heavily tied in to webkit. it would be a _far_ better design to be
passing in a struct containing function callbacks (rather a lot of
them - about eighty!) and then what you could do is have a "console"-
based port of webkit, which would do the job you needed.
alternatively, if you don't mind wrapping a binary application with
e.g. Popen3 then look at the webkit DumpRenderTree application, paying
particular attention to using the --html option. you won't have any
control over how long the javascript is executed for. after an
arbitrary and small period of time, DumpRenderTree _stops_ executing
the javascript and prints out the HTML DOM model (in a non-html-layout
fashion - it's used for debugging and testing purposes but will
suffice for your purposes).
so, as it stands, pywebkitgtk is _no worse_ than pykhtml, but with a
little bit of tweaking, the "gtk" could be removed from "pywebkitgtk"
and you'd end up with... ohh... call it "pywebkitglib" ... which would
be much better as a stand-alone library, for your purposes
then there's also "spidermonkey", which is mozilla's javascript
engine. i haven't investigated this option: haven't had a need to.
then there's also PyXPCOMExt, which is embedding python into mozilla,
and from there you have PyDOM, which allows you access to the DOM
model of the mozilla "thing". so, if you don't mind embedding your
application into XULRunner, you've got a home for executing your app
and obtaining the urls, post-javascript-execution.
the neat thing about PyXPCOMExt is that you have complete and full
access to python - so your app can make external TCP and UDP sockets,
you can embed an entire _server_ in the damn thing if you want (you
could embed... python-twisted if you wanted!) you can access the
filesystem - anything. absolutely anything. reason: the _entire_
python suite is embedded into the browser. every single bit of it.
that's about all i've been able to find, so far. there might be more
options out there. not that there aren't enough already :)
all of them will allow you complete and full access to execution of
javascript, including AJAX execution. which is why you'll need to do
that "polling" trick in many instances.
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python on JavaScript VM's (such as V8)?
On Oct 7, 10:15 pm, Fuzzyman <[EMAIL PROTECTED]> wrote: > On Oct 2, 1:06 pm,lkcl<[EMAIL PROTECTED]> wrote: > > > On Sep 3, 10:02 pm, [EMAIL PROTECTED] wrote: > > > > Berco Beute: > > > > > I wonder what it would take to implement Python inJavaScriptso it > > > it's been done. http://pyjamas.sf.net > > That's hardly an implementation of Python inJavascript- someone _is_ considering validating the pyjs.py interpreter to ensure that it's NP complete. however, it's an academic exercise that's not driven by an actual real-world need. basically, running pyjs.py and the standard python 2.5 "compile" module under pyv8. just for kicks :) so, the beginnings of the process - to bootstrap your way entirely into javascript-land, where you'd be able to "input" python and have it compiled _to_ javascript _by_ a python-to-javascript compiler which _itself_ has been compiled to javascript - the foundations have been laid. and it's not _as_ crazy as it sounds. sufficient tests to demonstrate unequivocably that the equivalent javascript _is_ equivalent; you then have pyv8 empirically demonstrating a ten times - TEN times for goodness sake - performance increase - that's got to be worth it. especially if it can be done "automagically", behind the scenes, so that when you type "python myapp.py" instead of executing forth-like byte code (myapp.pyc) you "execute" javascript (myapp.pyj). > it's a > partial Python toJavascripttranslator. compiler. python to javascript _compiler_ :) with a more complete python-to-javascript compiler in http://code.google.com/p/pyjamas subversion - you'll need the llpamies branch, but you'll _also_ need to go back to around sep 2007. somewhere in between then and now, luis tried to add proper support for **kwargs and he didn't complete it. > Still looks good though. yeh :) -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> >> You can remove layouts from layouts with the QLayout.removeItem() method. > > yes... it didn't work. a layout within a layout - i think it was a > > QHorizontalLayout within a QGridLayout - didn't want to be removed. > > it's probably a bug. > Was it detached from the layout, but still visible? i don't know if it _was_ detached from the layout, but it was definitely still visible. see http://pyjs.org/examples/gridtest/output/GridTest.html for the example i was porting to pyqt4. each time i clicked "Next", a new set of N,N would be _overlaid_ on top of the old ones, even though i was doing removeItem(). the code's at http://lkcl.net/pyjamas-desktop/pyqt4.tgz although i'm interested to know if there's a solution (to this particular problem), the amount of additional work to provide an equivalent of the "1px", "10em", "25%" etc. subdivisions on layouts, and the amount of additional work to provide "flowing" and HTML- substitutable layouts (see http://pyjd.org/api/pyjamas.ui.HTMLPanel-class.html) is just... it's a lot of work. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> Although using browser technologies for desktop applications is > interesting (and not new by any means), there are a few things with > regard to layouts which are very difficult with Web technologies (and > aren't getting any easier, either) but which are almost trivial with > classic graphical user interface toolkits, and of course there are > cases where the roles are reversed. if it wasn't for luis pamirez's brilliant work, porting pygtk to pyjamas, i would be absolutely agreeing with you, 100%. see this: http://code.google.com/p/pyjamas/wiki/GsocLlpamies luis has demonstrated that it's possible to have your cake and eat it. effectively - incredibly - he's ported pygtk ... to the browser! so your python pygtk application gets compiled, along with his reimplementation of gtk.py, gdk.py etc., into javascript (using the pyjamas compiler) and - unmodified - your pygtk app gets to run in every major web browser. that's just... stunning. regarding what you say about web technologies being more difficult to do layouts than traditional desktop apps - i'm really sorry to say that, from my experience with using the pyjamas widget set API, i couldn't agree less. HOWEVER - if this were pure HTML and CSS, i would utterly, utterly be agreeing with you - 100%. the first paragraph of my talk for ukuug 2009 says it best: http://ukuug.org/events/linux2008/programme/abstract-LKCLeighton-2.shtml it was _such_ an abortion trying to do a simple centred layout. and it's for exactly this reason that GWT was created (and then pyjamas ported from GWT). when you're using javascript to manipulate the DOM model (or, in the case of pyjamas-desktop, manipulating the DOM model directly) then it's an _entirely_ different matter. then, when you put "standard"- like widgets which include layout manager on top of _that_, which have identical functions and functionality to those of Desktop Widgets... ... the distinction between "web" and "desktop" suddenly becomes... moot. especially in the context of luiz's work. there isn't a _single_ thing that pyjamas can't do that pygtk2, wxWidgets or pyqt4 can do. there are _lots_ of things that pyjamas can do that pygtk2, wxWidgets and pyqt4 can't do (as they stand. without extra work and/or extensions e.g. derivative customised classes based on QAbstractLayout) ok - i'm exaggerating a little :) you can't access standard python modules from pyjamas apps in a web browser, because javascript is a restricted execution environment, so you have to make do (and you can make do _extremely_ well with what's available) with the provided implementation of builtins. so, if you don't mind using XMLHTTPRequest to communicate with the rest of the world - even if it's on http loopback - _then_ you're ok :) and yes, XMLHTTPRequest is supported in pyjamas-desktop (it has to be). also, writing new layouts and new widgets, which _happen_ to operate underneath on the DOM model of a browser (or a browser-kit-library such as PyKDE or PyWebKitGTK) is trivial. _really_ trivial. i've outlined how to write your own widget, here: http://pyjd.sourceforge.net/controls_tutorial.html and it's interesting to compare that to writing one for pygtk (there's a "stars" example which is easy to find "python gtk tutorial" i think it's hit number 3). the only thing i _can_ say, for definite, is that because pyjamas is missing an equivalent of glade, the UI-generator, and those GUI-based UI editors / designers, it _is_ at the moment a bit more... hard work doing the UI design manually, if you're used to using a GUI tool to design your UI. but i'm sure that will change. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 9:12 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > lkcl wrote: > > On Oct 11, 11:17 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > >> lkcl wrote: > > >> I got the impression that there is currently no Windows binary > >> available. Correct? If not, perhaps someone trustworthy will someday > >> donate one. > > > sorry, terry, you deleted a bit too much context :) > > I was referring to this at pyjd.org: > > Pre-built amd64 .debs are available for download, providing > pywebkitgtk-1.0, libwebkit-1.0-2 and libwebkit-dev, here: > > * Download libwebkit-dev, libwebkit-1.0-2 and pywebkitgtk-1.0 thanks for confirming, i thought so. > and this > >> If not, perhaps someone trustworthy will someday donate one. > > was my acknowledgement that a Windows binary is not trivial ha ha - i found that out :) > and that I > don't expect one from you after all the nice work you have done. thanks. > [compiling with mingw32] > > > why the python developers didn't include the patches, and keep them up- > > to-date, isn't clear. > > Mostly likely because no one who uses mingw32 has volunteered to become > the mingw32 Python developer who would update such patches to current > Python (now 2.6/3.0) and support them by responding to bug reports and > by upgrading them to 2.7/3.1 in the next few years. *nods head side-to-side*... yeahh, good point :) -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> if there's a way to enforce the displaying of text - for the _text_ > to say "i need to be a total area of X in order to display my words. > if you make my width too small, i will _force_ my height to be larger > as i wrap the text". > > just like an HTML does. ... of course, i'm well aware of the reasons _why_ this isn't supported - in either of Qt4 or Gtk2. it's because automatic- resizing, and correct (i.e. exact) size-hinting, is a complete lairy nightmare to implement. browsers get it right, because they have to, and the trade-off is a rather awkward judder-judder-displaying of content (which, for example, gives the use of HTML tables such a bad name). all of which of course makes the desktop-app developers' job just that little bit more awkward... -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 9:59 pm, Orestis Markou <[EMAIL PROTECTED]> wrote: > Just want to say, thank you for a very enlightening writeup. You > should really post this somewhere that we can link to. orestis, thank you for the encouragement. i did post it on my diary: http://advogato.org/person/lkcl/diary/523.html - i decided against doing a full-blown article because i've been doing quite a _lot_ of writing on advogato :) but i'm reconsidering. will post here if i do. i note with interest your comments here: http://orestis.gr/blog/2008/09/19/random-gui-toolkits-web-and-python/ whilst pyjamas and pyjamas-desktop are definitely cross-browser, cross- desktop, cross-platform and can even be made to be cross-widget-set, there isn't anything to substitute for _design_ ethos on a per- platform basis. by that i mean, expectations of there being a "File" menu on which the word "Quit" will occur, or, as you point out, mac- user expectations of application behaviour. l. -- http://mail.python.org/mailman/listinfo/python-list
Compiling Webkit-Glib and PyWebkitGTK for Win32
On Oct 13, 4:03 pm, Propad <[EMAIL PROTECTED]> wrote: > > the bottom line is: if you want a windows version of pywebkitgtk, i'm > > happy to assist and advise anyone of the process- it should be quite > > straightforward _if_ you have MSVC and follow the standard > If Visual Studio 2005 suffices, I'd give it a try. ok. let's change the subject it's bog-standard compile-procedure for webkit, under VS, but you must add in the patch for the glib bindings. you'll need a _hell_ of a lot of libraries. read this: http://lkcl.net/webkit/cross-compile-gtk.notes.txt and of course ignore mingw32 bits - use it to track down the locations for the various libraries in win32 form, including the .a files. you'll need cairo, gtk, gdk, libxml, libxslt and libicu. ibm's moved that on to version 4 and it's compiled up for win32 already. do make yourself known to the #webkit-gtk team on irc.freenode.net and ask for their help. _do_ use the code i have at github.org, use the 16401.master branch, i do not recommend attempting to use the latest svn plus the patch at bugs.webkit.org because alp has moved things on a bit and i haven't the time to update to the latest svn and redo the patch. http://github.com/lkcl/webkit/tree/16401.master then, once you have a libwebkit.dll, you'll be in a position to recompile pywebkitgtk for windows. this should be very very straightforward: there's nothing out-of-the-ordinary, other than you must patch it, use the last download / attachment from here: http://code.google.com/p/pywebkitgtk/issues/detail?id=13 i'm not _entirely_ sure how you go about compiling a c-based python module under windows, esp. one that requires autoconf: perhaps someone else here can advise, but if i was to be doing it, i'd start off by installing MSYS, locating a windows version of autoconf and gnu make and friends, and seeing how far i could get from there. you'll definitely need a windows version of python-gtk2 first, though, which will, aside from anything, give you lots of clues as to how to go about compiling pywebkitgtk - it's exactly the same principle. the reason why you'll need python-gtk2 is because of codegen.py - that is used to turn the webkit.defs into a webkit.c file. good luck! :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Safe eval of insecure strings containing Python data structures?
On Oct 13, 6:12 pm, George Sakkis <[EMAIL PROTECTED]> wrote: > On Oct 13, 8:36 am,lkcl<[EMAIL PROTECTED]> wrote: > > > > > On Oct 9, 4:32 am, "James Mills" <[EMAIL PROTECTED]> wrote: > > > > On Thu, Oct 9, 2008 at 2:26 PM, Warren DeLano <[EMAIL PROTECTED]> wrote: > > > > JSON rocks! Thanks everyone. > > > > Yes it does :) > > > > > Ben wrote: > > > > >>More generally, you should never execute (via eval, exec, or whatever) > > > >>*any* instruction from an untrusted path; especially not arbitrary > > > >>data from an input stream. > > > rubbish. this is why a project i was involved with, to do execution > > of code from a database instead of a filesystem had to be abandoned, > > back in 2001. > > > there are perfectly good systems for associating security context > > with "arbitrary data" (as the security models of SE/Linux, based on > > Flask, and the security model of windows nt, based on VAX/VMS > > security, show). > > > there was a flawed design decision in python 2.2 or python 2.3 which > > resulted in an "escape route" - i believe it centered around either > > __class__ or __new__ - in the c code, which the developers had not > > considered, and would not correct. > > > this decision resulted in the abandonment of the rexec.py module in > > python: you can see for yourself because it raises a runtime exception > > when you try to use it, issuing a warning. > > > it's _perfectly_ possible to define security contexts and boundaries, > > and to allow access to functions and modules on a per-security-context > > basis. > > > *as defined by the application developer* [not by the developers of > > python itself] > > > if an individual developer wants to allow "arbitrary code execution > > from any data stream", it most certainly is _not_ anyone's place to > > dictate to them that they "cannot do this". > > That's why eval and exec still exist (and will probably be around for > a long time, if not forever). If you define your own external to > python security contexts, what did the deprecated rexec buy you that > eval/exec don't ? * being able to store python modules in a mysql database! * being able to add context to selecting which python module and which python function should be retrieved from the db (*1) * being able to "vet" function names, allowing only those which are supported routines (out of the database) and banning all of the "standard" modules. (*1) the context in which rexec.py was being used was for a data centre "scanner" tool. a really damn good one, too :) some five years later, we got things like nessus and the other scanner tools being able to do "ping escalation", automated installs, ssh login checks etc. etc. but this tool was written in early 2001 (!) what we had was a 3-way-join on database tables: * asset, comprising an id, name, OS name and IP address * scripts, comprising an id, script content and the "module" name * the scripts-to-os-mapper table, comprising an id, "module" name and OS name the 3way join was between asset.os-name and scripts-to-os-mapper.os- name; scripts-to-os-mapper.module-name and scripts.module-name. the implications were that we could write per-OS modules (each with identical function names, function parameters and purpose, of course). then, if the customer decided that they wanted NT 4.0 instead of Redhat 5, we simply changed the OS type in the assets table, called up the "installOS" script, and it would be up to the 3-way-join to select the appropriate script for the job. no other work on our part was needed (yes we had an automated way to network-install NT 4 and Windows 2000). the example i remember best was "loginssh" - using the standard Popen python library - which of course was slightly different on a per-OS basis, because for NT there were CRLF issues to deal with, and also we had installed a commercial version of sshd which behaved differently. regarding exec / eval: yes, i _have_ used that in a similar sort of way, in another project. catching Name exceptions when executing a piece of code, i would then retrieve the value for the variable which came up from the exception by a SQL database call (which, perhaps unsurprisingly, had been put there from a web interface). by substituting the retrieved value into a dictionary to be used as "locals" in the exec / eval call, i was able to repeatedly perform this trick until the exec / eval succeeded, or the patience of the user ran out. it was awfully inefficient - O(N^2) - but, given that the code being exec
Re: Compiling Webkit-Glib and PyWebkitGTK for Win32
> the reason why you'll need python-gtk2 is because of codegen.py - that > is used to turn the webkit.defs into a webkit.c file. this might help: http://aruiz.typepad.com/siliconisland/2006/12/allinone_win32_.html it includes python-gobject, python-gtk, gtk runtime and much more. exactly _how_ much help it will be, i don't know: you may need instead to track down the (individual) libraries instead, in order to get the header files and appropriate .libs. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 13, 10:56 pm, David Boddie <[EMAIL PROTECTED]> wrote: > On Monday 13 October 2008 11:42, lkcl wrote: > > > i don't know if it _was_ detached from the layout, but it was > > definitely still visible. see > >http://pyjs.org/examples/gridtest/output/GridTest.html > > for the example i was porting to pyqt4. each time i clicked "Next", a > > new set of N,N would be _overlaid_ on top of the old ones, even though > > i was doing removeItem(). > > Yes, it just sounds like you needed to delete the layouts after removing > them. > > > the code's athttp://lkcl.net/pyjamas-desktop/pyqt4.tgz > > I might take a look later in the week if the code in there is runnable. yeah, it is. hello_loader.py is the main err um i just double- checked, so i'd be able to advise you and... err... the problem i described (with the GridTest) seems to have... gone away!! *slightly embarrassed* :) however, clicking too fast _did_ end up with fifty little windows of text (!) and the respect for text boundaries is definitely broken - shrink the window to 300 x 400 with the kitchensink example (which is where i stopped and moved to webkit, so all the _other_ examples prior to that will work) and you'll see that the text in a column down the left hand side end up all overlapping each other. so, you get to see the top few pixels of each word. if there's a way to enforce the displaying of text - for the _text_ to say "i need to be a total area of X in order to display my words. if you make my width too small, i will _force_ my height to be larger as i wrap the text". just like an HTML does. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
On Oct 15, 12:27 am, greg <[EMAIL PROTECTED]> wrote: > Paul Boddie wrote: > > there are a few things with > > regard to layouts which are very difficult with Web technologies (and > > aren't getting any easier, either) but which are almost trivial with > > classic graphical user interface toolkits, and of course there are > > cases where the roles are reversed. > > I've written quite a lot of desktop gui apps, and I > don't think I've ever felt the need for free-flowing > widget layouts. i have. an image library. placed in a scrollpanel, the images automatically flow left-to-right then down the page. the application doesn't dictate what size of panel the user _must_ view the images in. if they want to use the whole screen width, they can. if they want to view the images in a single column, they can. > To say that a desktop gui api is > severely lacking without this feature is somewhat > overstating the case. it's the _combination_ of the limitations that makes them severely lacking. each limitation on its own does not, of course. the key point is, really, that if you take away one particular layout methodology from designers, they _will_ adapt - they _will_ cope, and rejig the design of the app to fit the widget set. ... but that's cart-before-horse. that's "IT tail wagging the business Dog". so, when it comes to moving the same application functionality to a different platform, or to the web, people freak out. you're locked in. the cost is too great. the effort is too much. ... as you might be aware, i'm not really a big fan of restrictions imposed by software design :) > Also, I think that proportional resizing is overrated. proportional resizing is very difficult to do well, and so many people don't even consider it. many designers will say "this app is to be used on a 1024x768 screen" (and now of course they're running into difficulties with the netbook pcs with the 1024x600 screens, and KDE's control panel "close" button is now off-screen for example!) it took several months to design a 2d graph widget which was "useful" when scaled down to 200x150, especially given that the axes could be logarithmic (!) starting with the axes themselves, we had to break things down into small, medium and large graticules, where the distance between each range of graticules would no longer be displayed, below a certain number of pixels (5 or so). likewise with the axes numbering. then the axis description had to go, below a certain size. then, we had controls (sliders and dials) where, again, the graticules automatically disappeared, and, also, if below a certain size, the "readout" would also disappear. so if you're doing _simple_ applications, then yes, proportional resizing is entirely unnecessary. but if you're doing applications where you have to display vast amounts of interactive graphical data (the example above was a real- time digital audio restoration GUI) then you really do have to think a bit harder about what you're going to present the user with. > Proportional resizing is a > compromise that just ends up annoying me. if it's done badly, then yeah, i agree. if you look, for example, at the source code of my web site, http://lkcl.net/site_code, you'll see that the site is capable of resizing to deal with anything down to about 300 pixels in width. the onResize function redoes the layout, placing the seven components in a hexagon if there's space, a side-on "H" below 800 pixels, and a single line below 640 pixels. it didn't take too much effort, and it means that anyone viewing my web site even on a QVGA screen won't have to do horizontal scrolling. not that i'm _expecting_ anyone to do that - i just wanted to prove a point :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGUI as a standard GUI API for Python?
> > hello_loader.py is the main err um i just double- > > checked, so i'd be able to advise you and... err... the problem i > > described (with the GridTest) seems to have... gone away!! > > There are lots of references to PyGTK classes in there. yes, that's because i had started with the gtk port, and was going through the examples one-by-one removing them and replacing them with qt. as i only got up to the "Info" tab of KitchenSink, there is still quite a bit to do. i _say_ quite a bit - but it's only about ... 16-24 hours of work. pyjamas is surprisingly small. > Is there a way to select Qt instead of GTK? sorry! removing them :) > Hacking the code a bit, :) > I can run the hello_loader.py example. The items > on the left do indeed overlap. It looks like the minimum size of the > labels aren't being respected for some reason. yeah. and the pyjamas ui.HTML() class is based on a Qt.QLabel(). if that can be fixed, then there's a fair good reason to continue. > Yes, there are ways to relate the height of a widget to its width, and > there may well be a way to do that for a standard text widget, but it > might involve some experimentation with the underlying text document. *sharp intake of breath* :) yehhh, i did word-breaking by wrapping groups of 8 letters at a time in floating-divs once, to simulate word- breaking in a situation where the column width was 200px and people were putting in web site addresses of 50 chars in length yukk. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling Webkit-Glib and PyWebkitGTK for Win32
terry, hi: instructions to ensure that you have the right build environment for windows is here: http://webkit.org/building/tools.html it's not made clear whether the use of VS 2005 will _automatically_ download all of the build dependencies for you - you'll have to find out :) regarding pywebkitgtk: http://www.python.org/doc/2.5.2/ext/win-cookbook.html not sure how much use this will be, but i'm sure you'll definitely need gnu autoconf and friends, so i'd start here: http://gnuwin32.sourceforge.net/ l. -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.6, 3.0, and truly independent intepreters
On Oct 30, 6:39 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > Their professor is Lars Bak, the lead architect of the Google > V8Javascriptengine. They spent some time working on V8 in the last couple > months. then they will be at home with pyv8 - which is a combination of the pyjamas python-to-javascript compiler and google's v8 engine. in pyv8, thanks to v8 (and the judicious application of boost) it's possible to call out to external c-based modules. so not only do you get the benefits of the (much) faster execution speed of v8, along with its garbage collection, but also you still get access to external modules. so... their project's done, already! l. -- http://mail.python.org/mailman/listinfo/python-list
Re: push-style templating - an xml-like way to process xhtml
On Nov 2, 11:19 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> Push-style though enhances the risk of mixing program logic with
> presentation-logic (as simple print-statements do), and makes it a
> precondition that anybody who's supposed to tinker with the softare
> needs to be knowledgable in Python as well as in HTML.
i'd like to add perhaps a different perspective. i've developed and
used the following:
* xmlvl (http://sf.net/projects/virgule) - it's a (non-NP-complete)
XML-based programming language, which was derived from advogato's
codebase. it outputs XHTML, is "template-based" and implements what
is best described as an XML-based lattice-like, "crystalline" and
hierarchical OO database (!!). i understood it while i was writing
it, but woudldn't dare go near it, ever again.
the lessons learned from this were: don't take templating to extremes
(i.e. do the absolute minimum), and never ever write programming
languages in XML.
* python-htmltmpl (http://htmltmpl.sourceforge.net/) - it's a simple,
utterly simple, HTML-syntax-like templating language, which can do
"substitution", "if/else statements", and "loops". that's about it.
the nice thing about htmltmpl is that it can do pre-compilation of its
templates, inserting jump-points (which are used to seek() to the next
precompiled statement) into the .tmplc files. this saves a _great_
deal of time and CPU cycles.
the lesson from this one is hard to get across, because htmltmpl
basically... works. it doesn't _need_ developing, it's complete, it
works, it's never going to get up in the sourceforge "rankings"
because... it does everything that it's designed to do.
so it drops off of people's radar, and they reinvent the wheel.
if you think you need anything more than htmltmpl, which separates out
html from programming, think again. you can pass in a list of
dictionaries into htmltmpl, that generates the table content, form
content, whatever-content.
job done.
* pyjamas (http://pyjs.org) - this is treating the web page and the
web browser as a desktop "canvas", i.e. turning the web browser
concept on its head, and allowing you to program it in exactly the
same way that you would if you were writing a desktop app with PyQt4
or PyGtk2.
no kidding about, here.
why on earth would you want to do something like this? it's very
simple: HTML "programming" is madness. it's madness from two angles:
1) CSS abortions. as an example: i tried doing a centred-box, once.
it took two weeks, and it still was a failure: worked fine in firefox,
but in IE6 if you squashed the browser size, so that normally under FF
you got a horizontal scrollbar, what happened in IE6 was that the
content scrolled off the *top* of the screen!! unbelievable - and
completely impossible to fix.
2) HTML template "option-itis" resulting in thousands of lines of HTML
that becomes impossible to read, and impossible to maintain. i think
the worst example i ever saw - and i'm sure people will find worse -
was a technique involving _four_ separate near-identical pages (each
over 3,000 lines long) - one for new entry form, one for new entry but
with error-messages interspersed, one for edit, and one for edit but
with error-messages interspersed. cut-and-paste gone mad.
HTML templating is, for complex applications, a bd idea. even
when you start "breaking down" the content into smaller server-side-
includes, and even when you start doing multi-layered HTML templating
(one template gets marked up and then substituted into another
template and so on), even _that_ technique gets very quickly out-of-
hand and you're left with a headache.
so now i choose pyjamas over _any_ kind of web programming, any day of
the week.
the reason is very straightforward: the amount of code being written
is small; it's in python; i can re-use classes and modules; i can even
take standard python modules such as an XMLRPC client or a JSONRPC
client and actually compile them (to javascript) for use... in a web
browser!
you can put in a < div > with an id, you can find that div using a one-
line function, and you can substitute "widgets" - your classes - into
that div. it's a very, very powerful technique.
complex application programming should be done in a complexity-capable
programming _language_.
HTML, which is a markup language, is simply not designed - and was
never designed - to be "programmed" or to be an NP-complete
programming "language". it's great for "static content", which can be
edited by graphical tools, and that's about it.
so, there _is_ an alternative approach, with pyjamas, to what you're
saying, diez ("Push-style ... anybody who's supposed to tinker with
the softare needs to be knowledgable in Python as well as in HTML.")
the alternative is: program the entire web site in pure python. as if
it was a pygtk2, pyqt4 or python-wxWidgets desktop application.
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for a nitty-gritty Python Ajax middleware script to fire off a number of processors
On Nov 7, 10:38 am, Shao <[EMAIL PROTECTED]> wrote: > Dear All, > > I am looking for a nitty-gritty Python Ajax script to fire off a > number of processing programmes, periodically checking their > operations, sending messages back to an HTML div form by sending back > the links of generated data files, to be downloaded by end users. I am > using .NET IIS 6.0 and Windows Server. shao, hi, ajax is javascript, python isn't ajax, so there's an implicit dichotomy in what you're asking for _but_, there is this: http://pyjs.org - pyjamas: a python-to-AJAX compiler and web framework. you can therefore write application front-ends in python that get compiled into AJAX, to run on a web browser. the standard pyjamas user-interface API is _very_ similar to pyqt4 and pygtk2. documentation online is quite comprehensive, latest addition is: http://pyjs.org/book/output/Bookreader.html that takes care of the front-end, and a description of how to use AJAX, including ways to use at least four different JSONRPC back-end server frameworks is described here: http://pyjs.org/book/output/Bookreader.html#Rest%20of%20the%20World the alternative is for you use a javascript-based AJAX library in standard HTML, from any back-end server framework of your choice, coding up the front-end using custom-written javascript. the reason you need to write it yourself is that, although many of the python frameworks come with a _bit_ of AJAX included, it's usually as part of the "admin" interface: none of the back-end server frameworks are sufficiently sophisticated to include the kind of custom functionality you require. except pyjamas, which is a full-on compiler, turning python code into AJAX code, but that's for use in the front-end. good luck, l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Django or TurboGears or Pylons? for python web framework.
> On Wed, 05 Nov 2008 08:35:23 +0200, 3000 billg <[EMAIL PROTECTED]> > > Just from my preferences, I want to useDjangobut the AJAX support will > > be > > a problem. Also I need to select a JavaScriptframeworkand lean it, > > maybe > > JQuery, mootools or other. And I can not writepythonas it is written in > > general javascript. I need to learn a different syntax. yes, you can write python - and have it compiled to AJAX: http://pyjs.org > > Could everybody give me a hand for your select?Djangoor Turbegears or > >Pylons? and Why? > > IfDjango, how to do Ajax support for you? and why? pyjamas. then you get to write the front-end in python _and_ the back-end in python. see http://pyjs.org/book/output/Bookreader.html#Rest%20of%20the%20World which will help you to choose at least between django and web.py for AJAX-based frameworks, as there are four example techniques illustrated to do JSONRPC. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing/Crawler Questions - solution
On Mar 7, 12:19 am, [email protected] wrote: > So, it sounds like your update means that it is related to a specific > url. > > I'm curious about this issue myself. I've often wondered how one > could properly crawl anAJAX-ish site when you're not sure how quickly > the data will be returned after the page has been. you want to look at the webkit engine - no not the graphical browser - the ParseTree example - and combine it with pywebkitgtk - no not the "original" version, the one which has DOM-manipulation bindings through webkit-glib. the webkit parse tree example is, despite it being based on the GTK "port" as they like to call it in webkit (which just means that it links with GTK not QT4 or wxWidgets), is a console-based application. in other words, despite it being GTK, it still does NOT output graphical crap to the screen, yet it still *executes* the javascript on the page. dummy functions for "mouse", "keyboard", "console errors" are given as examples and are left as an exercise for the application writer to fill-in-the-blanks. combining this parse tree example with pywebkitgtk (see demobrowser.py) would provide a means by which web pages can be executed AT THE CONSOLE NOT AS A GUI APP, then, thanks to the glib / gobject bindings, a python app will be able to walk the DOM tree as expected. i _just_ fixed pyjamas-desktop's iterators in the pyjamas.DOM module for someone, on the pyjamas-dev mailing list. http://github.com/lkcl/pyjamas-desktop/tree/8ed365b89efe5d1d3451c3e3ced662a2dd014540 so, actually, you may be better off starting from pyjamas-desktop and then cutting out the "fire up the GTK window" bit, from pyjd.py. pyjd.py is based on pywebkitgtk's demobrowser.py the alternative to webkit is to use python-hulahop - it will do the same thing, but just using python bindings to gecko instead of python- bindings-to-glib-bindings-to-webkit. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Parsing/Crawler Questions - solution
On Mar 7, 9:56 pm, "bruce" wrote:
>
>
> and this solution will somehow allow a user to create a web parsing/scraping
> app for parising links, and javascript from a web page?
not just parsing the links and the "static" javascript, but:
* actually executing the javascript, giving the quotes page quotes a
chance to actually _look_ like it would if it was being viewed as a
quotes real quotes web browser.
so any XMLHTTPRequests will _actually_ get executed, _actually_
result in _actually_ having the content of the web page _properly_
modified.
so, e.g instead of seeing a "Loader" page on gmail you would
_actually_ see the user's email and the adverts (assuming you went to
the trouble of putting in the username/password) because the AJAX
would _actually_ get executed by the WebKit engine, and the DOM model
accessed thereafter.
* giving the user the opportunity to call DOM methods such as
getElementsByTagName and the opportunity to access properties such as
document.anchors.
in webkit-glib "gdom" bindings, that would be:
* anchor_list = gdom_document_get_elements_by_tag_name(doc, "a");
or
* g_object_get(doc, "anchors", &anchor_list, NULL);
which in pywebkitgtk (thanks to python-pygobject auto-generation of
python bindings from gobject bindings) translates into:
* doc.get_elements_by_tag_name("a")
or
* doc.props.anchors
which in pyjamas-desktop, a high-level abstraction on top of _that_,
turns into:
* from pyjamas import DOM
anchor_list = DOM.getElementsByTagName(doc, "a")
or
* from pyjamas import DOM
anchor_list = DOM.getAttribute(doc, "anchors")
answer: yes.
l.
> -Original Message-
> From: [email protected]
>
> [mailto:[email protected]]on Behalf
> Oflkcl
> Sent: Saturday, March 07, 2009 2:34 AM
> To: [email protected]
> Subject: Re: Parsing/Crawler Questions - solution
>
> On Mar 7, 12:19 am, [email protected] wrote:
> > So, it sounds like your update means that it is related to a specific
> > url.
>
> > I'm curious about this issue myself. I've often wondered how one
> > could properly crawl anAJAX-ish site when you're not sure how quickly
> > the data will be returned after the page has been.
>
> you want to look at the webkit engine - no not the graphical browser
> - the ParseTree example - and combine it with pywebkitgtk - no not the
> "original" version, the one which has DOM-manipulation bindings
> through webkit-glib.
>
> the webkit parse tree example is, despite it being based on the GTK
> "port" as they like to call it in webkit (which just means that it
> links with GTK not QT4 or wxWidgets), is a console-based application.
>
> in other words, despite it being GTK, it still does NOT output
> graphical crap to the screen, yet it still *executes* the javascript
> on the page.
>
> dummy functions for "mouse", "keyboard", "console errors" are given as
> examples and are left as an exercise for the application writer to
> fill-in-the-blanks.
>
> combining this parse tree example with pywebkitgtk (see
> demobrowser.py) would provide a means by which web pages can be
> executed AT THE CONSOLE NOT AS A GUI APP, then, thanks to the glib /
> gobject bindings, a python app will be able to walk the DOM tree as
> expected.
>
> i _just_ fixed pyjamas-desktop's iterators in the pyjamas.DOM module
> for someone, on the pyjamas-dev mailing list.
>
> http://github.com/lkcl/pyjamas-desktop/tree/8ed365b89efe5d1d3451c3e3c...
> dd014540
>
> so, actually, you may be better off starting from pyjamas-desktop and
> then cutting out the "fire up the GTK window" bit, from pyjd.py.
>
> pyjd.py is based on pywebkitgtk's demobrowser.py
>
> the alternative to webkit is to use python-hulahop - it will do the
> same thing, but just using python bindings to gecko instead of python-
> bindings-to-glib-bindings-to-webkit.
>
> l.
> --http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
how do you prevent distutils from downloading and building packages without consent?
folks, hi, a number of people using pyjamas are not only encountering difficulties with setup.py endeavouring to download and install "setuptools" but also they are ... the best word to use is unfortunately "offended" - by the fact that distutils, in its default configuration, downloads and even _compiles_ its dependencies - *without consent*. a copy of the setup.py can be found here: http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/setup.py this alarming situation has shown to occur on windows, ubuntu and debian. personally, i used setup.py to install pyjamas on a debian system: as i happened not to have python-setuptools installed, i was alarmed to find that setup.py, thanks to distutils, was not only downloading but also attempting to _compile_ setuptools. fortunately, the compile actually failed. windows users have also reported similar failures (presumably because the do not have a suitable build environment, involving downloading and installing a proprietary c compiler) and have also expressed their displeasure at not being consulted as to which bits of software are going to get thrown onto their system without their permission. so it should be fairly clear as to why it is unacceptable for this to occur. the question is: how can it be stopped? what option, in distutils "terminology", tells distutils "please simply tells users that a package is missing, providing them with sufficient information such that they can rectify the missing dependency in a manner which is satisfactory _to them_? answers and guidance greatly appreciated, including telling me that i've made a simple mistake in the setup.py, linked above. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you prevent distutils from downloading and building packages without consent?
> read the setuptools documentation? Didn't you *test* your setup.py > before making it available to the world? yes - and it worked on my debian linux box. so, off it went. turns out that it worked because i had python-setuptools preinstalled. > > alarmed to find that setup.py, thanks to distutils, was not only > > downloading but also attempting to _compile_ setuptools. fortunately, > > the compile actually failed. > > What is so gut-wrenchingly awful about "compile" that you must > underline its every occurrence? :) the disparity between the expectations and the actual behaviour. but, given that both you and gabriel spotted that the setup.py uses setuptools (which i'm not familiar with) that would make sense. duh. that's what i was missing - thank you both, john and gabriel. i tend to cut/paste quite horrendous amounts of bits of code together. most of the time, it works. some of the time, i miss things. much appreciated that you pointed the mistake out. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do you prevent distutils from downloading and building packages without consent?
ok - john, gabriel, i've now removed setuptools, which is the area
that's problematic for many people. however there's a feature of
setuptools which _is_ useful:
-entry_points = {'console_scripts':[
- 'pyjsbuild=pyjs.build:main',
- 'pyjscompile=pyjs:main',
- ]},
whoops - those are now gone.
i have a command, bootstrap.py, which replicates that exact
functionality: it creates a customised pyjsbuild which can go in /usr/
bin or /usr/local/bin and it will add the library locations to
sys.path and also as a -D option to the pyjs main() function - it's a
little obscure, but works out fine.
e.g. if you specify no arguments, this gets auto-generated, in ./bin/
pyjsbuild :
#!/usr/bin/python
pth = '/home/lkcl/src/sf.pyjamas/svn-pyjamas/pyjamas'
import os
import sys
sys.path[0:0] = [
pth,
]
import pyjs, sys
pyjs.path += [os.path.join(pth, 'library'),
os.path.join(pth, 'library', 'builtins'),
os.path.join(pth, 'addons'),
]
sys.argv.extend(['-D', pth])
import pyjs.build
if __name__ == '__main__':
pyjs.build.main()
if you specify "python bootstrap.py /usr/share/pyjamas /tmp" you get,
in /tmp/bin/pyjsbuild:
#!/usr/bin/python
pth = '/usr/share/python'
import os
import sys
sys.path[0:0] = [
pth,
]
import pyjs, sys
pyjs.path += [os.path.join(pth, 'library'),
os.path.join(pth, 'library', 'builtins'),
os.path.join(pth, 'addons'),
]
sys.argv.extend(['-D', pth])
import pyjs.build
if __name__ == '__main__':
pyjs.build.main()
so, would you (or anyone else) happen to know how i can get setup.py
to run bootstrap.py to create these two scripts, in a way that's
compatible with the setuptools "entry_points" thing? i.e. taking the
option of "--install-data" as the first argument to bootstrap.py and
the option of "--prefix" as the second argument.
i envisage it to be something like:
from bootstrap import create_commands
if distutils.X.cmd == "build":
create_commands(distutils.XX.install_data_path,
distutils.XX.prefix)
but it all looks a bit hair-raising, if you ask me. i'm not often on
wobbly ground when it comes to python, but this is pretty specific
stuff that has to be got right across multiple platforms.
tia,
l.
--
http://mail.python.org/mailman/listinfo/python-list
Re: how do you prevent distutils from downloading and building packages without consent?
http://mail.python.org/pipermail/distutils-sig/2008-March/008925.html dang. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: read web page that requires javascript on client
On Mar 18, 8:01 pm, Greg wrote: > Hello all, I've been trying to find a way to fetch and read a web page > that requires javascript on the client side and it seems impossible. you're right: it's not impossible. > I've read several threads in this group that say as much but I just > can't believe it to be true you're right: it's not true. > (I'm subscribing to the "argument of > personal incredulity " here). there are several approaches that you can take that combine python and javascript: none of them are at the level of "simplicity" which you and many others may be expecting, which is why it's believed to be "impossible" or "not achievable". they all have different advantages and disadvantages - don't be surprised if you end up with 30 mb of binaries on your system, _just_ to support the features you're implicitly asking for, ok? here's the approaches i've found so far: 1) python-spidermonkey python-spidermonkey "rips out" the mozilla javascript engine and provides you with a hybrid mechanism where the execution context can be shared between the two languages. in other words, variables and functions can be shoved into the namespace of the spidermonkey javascript context and executed; python can likewise (in a rather clunky way at the moment) gain access to the execution context and "call in". what this approach does NOT have is the "DOM model" functions. those have been REMOVED as they are ONLY part of the W3C specification for implementation of web browsers, NOT the ECMAScript specification. 2) PyV8 - http://code.google.com/p/pyv8 take 1) above, and sed -e "s/python-spidermonkey/pyv8/g" flier liu, the author of pyv8, is actually _doing_ what you want to do. namely, he's started with a combination of python plus google's V8 javascript engine, and he's now moving on to implementing the DOM as *python*, for execution as a python console-only application. he recognises the need for execution of javascript, as part of the requirement, and that's the reason why he has added google v8. by doing this "hybrid", he will be able to "add" a global variable called "document" to the javascript context, and another global variable called "window" to the javascript context, etc. etc. and then "execution" of the javascript will result in callbacks - into python - to emulate, in its entirety, the complete W3C DOM model standard. far be it for me to tell him how monstrously large the task of reimplementing the W3C DOM standard in python, i urge you to consider helping him out with his project. 3) pywebkitgtk (+patch #13) + webkit-glib/gdom (+patch #16401) this one's a whopping-great project that takes the ENTIRE webkit engine, patched to include glib / gobject bindings, so that python can "get at" the DOM model, directly. you can use this to "execute" a web page - bear in mind that GTK apps do NOT have to be "visible" - you CAN "run" a GTK app WITHOUT actually putting up an on-screen GUI widget. in this way, you will be able to "load" a web page, have it be "executed", and then, after a specific and arbitrary amount of time, run some python using the python-bindings to the DOM model to either "walk" the DOM model or just call the "toString()" method and obtain a flat HTML representation of the entire page. CAVEATS: apple's employees are flexing their muscles and are unfortunately showing that they have power and control by limiting the functionality of the glib / gobject bindings to "that which they deem to be acceptable". apple's employees have deemed that strict compliance to the W3C standard is how they want things to be, and are ignoring the fact that the de-facto standard is actually that specified by Javascript implementations. in other words, toString, being a de-facto standard, is "unacceptable" to them, as are a couple of other things. 4) python-hulahop exactly the same as 3) except using mozilla not webkit: hulahop is the ENTIRE gecko engine, with python bindings via the XUL interface. the hulahop team are the ONLY people who have been able to understand the obtuse XUL interface enough to be able to make python bindings actually _work_ :) it's clear that the OLPC / SUGAR team looked at webkit, initially, and loved it. however, they saw the lack of glib/gobject bindings, and the lack of python bindings, and freaked out (whereas i, rather stupidly, went "nooo problem saah!" and _added_ glib / gobject bindings to webkit) so they then went "a, safety", abandoned webkit and made a beeline for XUL. so they have complete and total control over the DOM model, from python, including (thanks to gecko's ability to execute javascript using spidermonkey) the ability to interact two-way with javascript (exactly as can be done with webkit's glib/gobject + pywebkitgtk bindings). so - _again_ - you have the choice of being able to run a GTK app - without an actual "window" - load up a web page and then tell the XUL / Gecko engine "GO! EXECUTE JAVASCRIPT!", and then, at s
Re: read web page that requires javascript on client
On Mar 18, 8:25 pm, "R. David Murray" wrote: > Greg wrote: > > Hello all, I've been trying to find a way to fetch and read a web page > > that requiresjavascripton the client side and it seems impossible. > > I've read several threads in this group that say as much but I just > > can't believe it to be true (I'm subscribing to the "argument of > > personal incredulity " here). > > > Clearly urllib and urllib2 don't seem to support this and I've looked > > at win32com.client and it's ScriptControl but that doesn't seem to be > > viable approach for this particular problem. > > > Does anyone have any suggestions, hack or ideas or am I missing > > something really obvious. > > Well, this is what is called a Hard Problem :). It requires not > only supporting the execution ofjavascript(and therefore an entire > additional language interpreter!), but also translating that > execution into something that doesn't have a browser attached to it > for input or output. > > That said, I've heard mention here of something that can apparently be > used for this. I think it was some incarnation of Webkit. yep. patch #16401 - don't use the cut-down version that the other company who are doing "vala" bindings are using - use the version that i've worked on, until they support the "full" DOM bindings. better yet, just grab the code from the git repository i'm maintaining - http://github.com/lkcl/webkit/tree/16401.master > I remember > someone saying yep, it was me :) > you wanted to use the one with, I think it was GTK > bindings, even though you were dealing with just network IO. But I don't > remember clearly and did not record the reference. Perhaps the person > who posted that info will answer you, i do searches for the words "ajax" and "javascript" and "pyjamas" using groups.google.com occasionally, and pick things up - eventually :) > Unfortunately I'm not 100% sure it was Webkit. it was - however i've since found three other projects (including python-hulahop, the best other alternate candidate). l. -- http://mail.python.org/mailman/listinfo/python-list
Re: read web page that requires javascript on client
On Mar 20, 1:09 am, Greg wrote: > On Mar 18, 7:25 pm, Carl wrote: > > > > > On Mar 18, 1:56 pm, [email protected] (Aahz) wrote: > > > > In article , > > > R. David Murray wrote: > > > > >That said, I've heard mention here of something that can apparently be > > > >used for this. I think it was some incarnation of Webkit. I remember > > > >someone saying you wanted to use the one with, I think it was GTK > > > >bindings, even though you were dealing with just network IO. But I don't > > > >remember clearly and did not record the reference. Perhaps the person > > > >who posted that info will answer you, or you will be able to figure out > > > >from these clues. Unfortunately I'm not 100% sure it was Webkit. > > > > By the power of Gooja! > > > >http://groups.google.com/group/comp.lang.python/msg/aed53725885a9250 > > > -- > > > Aahz ([email protected]) <*> > > > http://www.pythoncraft.com/ > > > > "Programming language design is not a rational science. Most reasoning > > > about it is at best rationalization of gut feelings, and at worst plain > > > wrong." --GvR, python-ideas, 2009-3-1 > > > Probably the easiest thing is to actually use a browser. There are > > many examples of automating a browser via Python. So, you can > > programmatically launch the browser, point it to theJavaScript > > afflicted page, let the JS run and grab the page source. As an added > > bonus you can later interact with the page by programatically, filling > > form fields, selecting options from lists and clicking buttons. > > > HTH, Carl > > Selenium. It's not pretty for what I want to do but it works ... then > again, what I need to do is not pretty either. > Ciao, > Greg http://seleniumhq.org/projects/remote-control/languages/python.html intriguing. five solutions. although, using selenium forces you to actually have the full complete firefox web browser, including running the GUI itself, and then having a plugin actually in the browser itself. which is rather borked - but works. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embed a web browser into a page
On Feb 12, 12:44 am, "Carbon Man" wrote: > Hi, > I need to embed a web browser into a python page. I am coming from the MS > world where I created an app that all of it's interfaces were actually web "its" not "it's". "it apostrophe s" is short for "it is". so you've said "i created an app that all of it is interfaces were actually web pages. additions of apostrophes have resulted in lunar exploration rockets crashing, amongst other things (programs written in fortran...) > pages rendered in an Internet Explorer activex control. > wondering if there is a way to do something similar that would work > cross-platform? well, if you want to run python under wine, and attempt to install pythoncom-win32 under that, i _have_ had some success in getting python 2.5 to work as a wine application, and worked with the wine team to fix a number of critical bugs in the not-exactly-posix- compliant MSVCRT. so you _could_ conceivably get that up and running, and it would be _kinda_ cross-platform. don't even think of using python 2.7 yet because changes in python 2.7 make extensive use of message-mode NamedPipes, and the wine NamedPipes infrastructure doesn't support message-mode, and so screws up on critical things like the thread module. > I guess there is much more complexity in it when you start to go across o/s > platform boundaries. The common web interface would then be Gecko orWebKit? yes. so, therefore, you need to look at python-hulahop or pywebkitgtk with patch #13 and webkit-glib/gdom (webkit with patch #16401, or use my pre-patched tree - http://github.com/lkcl/webkit/tree/16401.master > So can someone suggest what would be required to build a cross-platform > Python app that was capable of browsing HTML files, receiving events from > the browser, and that allows the embedded page to call host Python modules > from Javascript via an object reference? Or I am asking too much :) you're not asking too much - you're just asking for a whopping great 30mb of dependencies, whichever way you go. if you'd like to help out, we _really_ do need builds of webkit for win32, patched, which took a week, last time i tried - see http://lkcl.net/webkit/cross-compile-gtk.notes.txt and then win32 builds of pywebkitgtk on top of _that_. either way, if you go the python-hulahop or the pywebkitgtk-patched + webkit-patched route, you're in for about two weeks non-stop of build / compilation / dependency-hunting, to get something going on win32. as i've done webkit-win32 once before, i will be in a position to help advise you (and the bugs in gcc i encountered will likely have been fixed by now in "official" releases). whereas the python-hulahop build process you're likely to be the first person ever, in the world, to try building python-hulahop for win32. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Embed a web browser into a page
On Feb 12, 9:22 am, "Diez B. Roggisch" wrote: > Carbon Man wrote: > > Hi, > > I need to embed a web browser into a python page. I am coming from the MS > > world where I created an app that all of it's interfaces were actually web > > pages rendered in an Internet Explorer activex control. There was a object > > hook that allowed you to call into the host environment from javascript. > > Basically the host environment would receive the documentComplete event > > and call a method in the document's Javascript passing in an object > > reference. That reference would then be available for calls to be made > > from Javascript back into the host environment. > > I am just starting to explore the Pythonic programming jungle and I was > > wondering if there is a way to do something similar that would work > > cross-platform? > > I guess there is much more complexity in it when you start to go across > > o/s platform boundaries. The common web interface would then be Gecko or > >WebKit? So can someone suggest what would be required to build a > > cross-platform Python app that was capable of browsing HTML files, > > receiving events from the browser, and that allows the embedded page to > > call host Python modules from Javascript via an object reference? Or I am > > asking too much :) > > The only thing that might work is Qt +webkitthat is used as it's browser. you mean "its browser". > Everything else is not cross platform. not quite true - python-hulahop should theoretically compile for win32 - it's just that nobody in their right mind has tried it :) l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Compatible JS Lib for Django
On Apr 4, 7:20 pm, Daniel Fetchinson wrote: > > Does anyone have experience with using JS Libraries with Django? yes - pyjamas - http://pyjs.org - although, strictly speaking, it's a python widget-set and python-to-javascript compiler. the possibility now of being able to program in python both client- side (to generate the front-end) and server-side is just _such_ a relief. i now almost exclusively use django and pyjamas, for all web development. > > Do some work better than others and are easier to code with? i just did a quick review of one of the alternatives to pyjamas - qooxdoo.org - which actually looks pretty good, except then you think "hang on a minute - this is near-identical functionality to pyjamas, i'm a python programmer, i'd have to get involved with javascript, what the _hell_ am i _thinking_!" http://groups.google.com/group/django-users/browse_thread/thread/9dad05e276c99a0c/d0c6dee57d89d376?lnk=gst&q=pyjamas#d0c6dee57d89d376 basically, pyjamas turns the web browser into a desktop widget set platform. apps are written in the same declarative style as python- qt4 and python-gtk2 and python-wxwidgets. all the browser incompatibilities are taken care of, with seamless per- platform overrides for Netscape, Mozilla, Safari, Opera and IE. so it couldn't _get_ any easier. you don't even need to know any javascript - just a bit of CSS and some HTML. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on JavaScript VM's (such as V8)?
On Sep 3, 10:02 pm, [EMAIL PROTECTED] wrote: > Berco Beute: > > > I wonder what it would take to implement Python in JavaScript so it it's been done. http://pyjamas.sf.net > > can run on those fancy new JavaScript VM's such as Chrome's V8 or that's been done, too. http://advogato.org/article/985.html > > Firefox' tracemonkey. Much the same as Python implementations in C# > > (IronPython) and Java (Jython). It would certainly bring back the fun > > in web application development. it's great :) been using it just for fun, for about 18 months. http://lkcl.net/site_code and for a personal project http://partyliveonline.com and for a commercial project which i'm sorry i can't refer you to the development site right now. > Is there anything done in that direction? yup. quite a lot. see http://groups.google.com/groups/pyjamas-dev > The mythical beast pypy is supposed able to translate Python to > Javascript too, I think. From some of my benchmarks Chrome's V8 is a > little slower than Psyco... so the matter is how much efficiently can > be Python translated in JS. well, the llpamies pyjamas branch from sep 2007 has some definite improvements in the _features_ provided (python-wise) but some time after that, one too many interoperability features were added (proper support for **kwargs) and it just... blew up, got too complicated for luiz and he abandoned the effort. i've outlined on pyjamas-dev what work needs to be done to satisfy both goals of remaining efficient and also providing support for **kwargs. one _much_ more important requirement - over-and-above "efficiency" (which isn't that bad anyway in pyjs.py) is readability. remember you have to _debug_ these ing programs in javascript, not python (which is why i did pyjamas-desktop - http://pyjd.sf.net so you could keep on using the standard python interpreter and _then_ run the same app through pyjs.py to convert it to javascript). l. -- http://mail.python.org/mailman/listinfo/python-list
Re: javascript to python
On Oct 2, 5:54 pm, Joe Hrbek <[EMAIL PROTECTED]> wrote: > Could someone help me translate to something that would close to it in > python? The anonymous functions are giving me problems. class dataListener: def __init__(self): data = "" def onStartRequest(self, request, context): pass def onStopRequest(self, request, context, status): # TODO: pass these three in to dataListener as # params to the constructor, so it's # def __init__(self, instream, outstream, listener) # and do self.instream = instream global instream global outstream global listener instream.close() outstream.close() listener.finished(self.data) def onDataAvailable(self, request, context, inputStream, offset, count): global instream self.data += instream.read(count) question. why are request and context being ignored? why is there an inputStream argument to onDataAvailable, yet there's a global variable (in the javascript) called instream? is it the same? all this, and more, thanks to the awfulness that is javascript :) for fits and giggles, compile the above python using pyjs.py, the python-to-javascript compiler (see http://pyjamas.sf.net) and compare the resultant javascript to your original code-fragment. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: javascript to python
On Oct 2, 7:42 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> lkcl a écrit :
>
>
>
> > On Oct 2, 5:54 pm, Joe Hrbek <[EMAIL PROTECTED]> wrote:
> >> Could someone help me translate to something that would close to it in
> >> python? The anonymous functions are giving me problems.
>
> > class dataListener:
> > def __init__(self):
> > data = ""
> > def onStartRequest(self, request, context):
> > pass
> > def onStopRequest(self, request, context, status):
>
> > # TODO: pass these three in to dataListener as
> > # params to the constructor, so it's
> > # def __init__(self, instream, outstream, listener)
> > # and do self.instream = instream
>
> > global instream
> > global outstream
> > global listener
>
> Since you don't rebind them, you don't need the global statement for
> these three identifiers
>
> > instream.close()
> > outstream.close()
> > listener.finished(self.data)
>
> > def onDataAvailable(self, request, context, inputStream,
> > offset, count):
>
> > global instream
>
> idem
>
> > self.data += instream.read(count)
>
> And then you have a class. Calling instance methods on the class won't
> work. Looks like there's something missing...
>
> > question.
>
> > why are request and context being ignored?
> > why is there an inputStream argument to onDataAvailable, yet
> > there's a global variable (in the javascript) called
> > instream? is it the same?
>
> > all this, and more, thanks to the awfulness that is javascript :)
>
> None of "this, and more" is because of javascript. You'll find bad code
> in every language (and without more context, you can't tell if it's bad
> code - might as well be the right thing to do).
>
> FWIW, javascript is a very interesting and powerful language.
>
> > for fits and giggles, compile the above python using
> > pyjs.py, the python-to-javascript compiler
> > (seehttp://pyjamas.sf.net) and compare the
> > resultant javascript to your original code-fragment.
>
> > l.
>
> I did. Here's the result:
ok - these are the "important" bits. notice that the pyjamas
compiler is doing a little bit more than your original code: it's
overriding the "prototype" of dataListener, making it a true "class"
object.
this is where there's a key departure from the original code and the
translation to python: the original code isn't actually a class, at
all - it's more like a c struct that has function pointers in it.
by declaring a python "class", the javascript equivalent is to add to
"prototypes".
> __dataListener.prototype.__init__ = function() {
> var data = '';
> };
[ ... so for example here, now when you declare _any number_ of
"dataListener"s, each and every one will have its __init__ function
called. in your original example, you're effectively making one and
only one "dataListener". you're kinda... it's a bit like having a
lambda-class (nameless class) and declaring one and only one instance
of that python class... ]
> __dataListener.prototype.onStopRequest = function(request, context,
> status) {
> instream.close();
> outstream.close();
> listener.finished(this.data);
> };
> __dataListener.prototype.onDataAvailable = function(request,
> context, inputStream, offset, count) {
> this.data += instream.read(count);
> };
so - yeah, you can see that (apart from the .prototype, which is
necessary to make a "class a la javascript") it's a pretty accurate
translation back to the original javascript.
> All this, and more, thanks to the strange idea that it would be better
> to write javascript in Python instead of writing it in javascript !-)
*lol* :) fortunately, pyjs.py does that translation for you ha
ha. like they say on brainiac, "STOP! we do these experiments, so
you don't have to".
yes - it's because in the translated python, dataListener was
declared as a class, whereas in the original javascript, the
corresponding concept (prototypes) are not made use of.
if you wanted to experiment, you could try this:
def onStartRequest(this, request, context):
pass
def onStopRequest(this, request, context, status):
instream.close()
oustream.close()
listener.finished(this.data)
def onDataAvailable(this, request, context,
inputSt
Re: javascript to python
On Oct 3, 10:29 am, Bruno Desthuilliers wrote: > lkcl a écrit :> On Oct 2, 7:42 pm, Bruno Desthuilliers > > <[EMAIL PROTECTED]> wrote: > >> lkcl a écrit : > Not 'mine' - I'm not the OP. whoops, yes - i missed that. sorry! > And as far as I'm concerned, the point is > exactly here : it's doing "a little bit more" than the original code. yeah, i know. and that "bit more" gets you a proper representation of the python "class" concept. i was merely pointing out that if you want to _really_ translate the original code into python - _really_ strictly - it's not actually possible. because python doesn't have the concept of non-prototyping (but... see below: i believe i may stand corrected on that) > [..snip..] and is > actually useless for the OP's use case (else the OP's code wouldn't use > litteral object notation but a full-blown prototype). i know :) > > it's > > overriding the "prototype" of dataListener, making it a true "class" > > object. > > There's nothing like a notion of "class" in javascript - as you of > course already know. okay,okay :) class-like :) > Indeed. But the point is that Python - while close to a prototype-based > language in many aspects - is still class-based. The closer Python > translation of the OP's javascript snippet is probably the one I gave > using a 'class singleton' - that is, using the class itself as an > object. oh is _that_ how you do it. thanks. i always wondered how you did class singletons in python. > python-source-to-javascript-source tool like pyjamas won't give you back > the original javascript snippet (which is by no mean a criticism of > pyjamas - it would just be way too complicated to automatize such a > translation). well... you _say_ that... but... actually, if that's the real way to represent class singletons, and it's an accurate representation of the OP's javascript, and a good example, then _yes_, pyjs should definitely have that added as a feature - to understand that a class singleton _can_ get mapped to the much more efficient javascript example you gave. not that many people would _want_ to do that, so it goes onto the "diminishing returns TODO list", but... > Nope. You defined functions outside the object's scope, and you still > have to instanciate dataListener. Also, this above code just won't work > - unless you explicitely pass the dataListener instance to the > functions, ie: > > d = dataListener() > d.onDataAvailable(d, ...) yeah - i didn't realise what the python class singleton thing was. > It seem you didn't read my other translation proprosal, so I repost it here: > class dataListener(object): > data = '' i did - i just didn't understand its significance. so - to get this straight: when you do class clsname(object), and you have the indentation and declaration of variables (e.g. data, above) at the same level as the functions, it means that there's only one of them? (i.e. a singleton)? so, if i do this: d = dataListener() e = dataListener() d.data = "fred" print f.data will return "fred"? l. -- http://mail.python.org/mailman/listinfo/python-list
Re: javascript to python
> so, if i do this: > > d = dataListener() > e = dataListener() > > d.data = "fred" > > print f.data duh, duh - that should be print e.data :) -- 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: 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: 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: 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: 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: 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: (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: 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: 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: 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 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 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 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 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 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 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: 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: 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
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: 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
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
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: 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
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, 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.
> 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 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
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
