On Wed, Apr 9, 2008 at 8:50 AM, Mike Orr <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 9, 2008 at 8:27 AM, Lawrence Oluyede <[EMAIL PROTECTED]> wrote: > > > > On Wed, Apr 9, 2008 at 5:08 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > > According to IRC yesterday, appengine doesn't allow C modules, so that > > > takes out Mako, SQLAlchemy, and parts of Paste and Setuptools. So it > > > will take a while to get any non-trivial Pylons app running on it. > > > > > > http://pylonshq.com/irclogs/%23pylons/ > > > > > > Let's be rational about this. I haven't tried app engine yet altough I > > have an account (plan to do it this weekend) > > but I'm reading a lot of stuff about it. > > > > My bigger concern (putting aside the terms of service for a moment) > > is: what's the point in porting existing libraries/frameworks and so > > on > > to make them work in the google infrastructure? > > > > Maybe I am short sighted but I guess it is too much work having two > > different versions of the framework "just for Google". > > You're discounting the "fun" effect: people want to see if they can > accomplish it. There is no "fork" of Pylons/Mako/Paste. Merely > people exploring the incompatibilities to see if the same package can > be made compatible for both environments. Or conversely, to go to > Google (or our man in Google, Guido), and say this restriction is > really unworkable for us for X, Y, and Z reasons. Because if it's > unworkable for us, it's unworkable for other Python frameworks and > packages that a lot of people making websites want/need to use, which > excludes Google from hosting said apps. Since they want apps on their > servers, and they're Python fans just like us, they may be interested > in doing something about it. Anyway, pkg_resources incompatibility > will give them a bigger headache in the long run than it gives us. > > The problem with C libraries is a lot bigger than just Google. It > frustrates users on Windows and Macintosh to no end, and many of them > give up trying to install Pylons/lxml/ToscaWidgets/wxPython and go on > to something else. Precompiled binaries don't always exist, are too > old, hard to find, or built with the wrong C compiler or Unicode > width. > > That's why we didn't use lxml in the WebHelpers upgrade. We looked > and finally found a pure Python module that did what we need. But > appengine has shown us there's a few other C dependencies to be worked > around if possible (without killing the performance). Because these > same problems presumably come up when porting Pylons to Jython, > IronPython, PyPy, etc. And if Django can do it and Pylons can't... :( >
You can always take the approach where C modules are used if available, otherwise pure Python code can be used. simplejson does this, for example. -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
